A blockchain-based invoice compliance verification system and method

Abstract

This invention discloses a blockchain-based bill compliance verification system and method, relating to the field of bill security technology. The invention constructs a topology network based on business data from the issuer and payee, extracts the core elements of the issuer's bill, generates an issue hash through hash calculation and signature, and outputs a benchmark topology data packet for the bill. It then extracts the payee's bill receipt request data, associates it with the benchmark data packet to verify the format, and generates a topology data packet to be verified. Consistency verification is performed by comparing the hashes of the original elements with those of the elements to be verified. When the hashes match, the bill hashes are aggregated to filter suspected collision groups, and collision types are distinguished based on topology network rules, with a report output. When the hashes do not match, the tampered fields are located and bit differences are analyzed. When a genuine collision is determined, the true elements of the bill are deduced based on the topology network, and a confirmation slip is generated. Finally, the entire process output is integrated, abnormal operation states are determined, and targeted processing is performed.

Description

Technical Field

[0001] This invention relates to the field of bill security technology, specifically a blockchain-based bill compliance verification system and method. Background Technology

[0002] As a core certificate for financial transactions and supply chain settlement, the compliance of negotiable instruments is directly related to transaction security, regulatory traceability, and protection of the rights and interests of all parties. However, existing methods for verifying the compliance of negotiable instruments still have some shortcomings.

[0003] Traditional methods generally do not consider hash collisions, and can only make a binary judgment of whether the hash calculation and the hash value of the signature unit are consistent or inconsistent. They neither anticipate hash collision scenarios nor have targeted classification and handling logic. When the hashes are consistent, they cannot distinguish between pseudo-collisions caused by duplicate submissions and real collisions caused by substantial conflicts in the document information, which easily leads to missed detection of real information conflicts and misjudgments of normal duplicate submissions. When the hashes are inconsistent, traditional methods do not design a traceability system associated with collision risks. They can only make a preliminary judgment that tampering has occurred, but cannot accurately locate the tampered fields. Furthermore, they lack quantitative analysis methods to convert the original and the elements to be verified into binary bit sequences, calculate the difference value and distribution, which hinders regulatory traceability and liability determination. Even if existing technologies detect real collisions, they cannot meet the needs of large-scale and complex transaction scenarios because there is no preset response plan and they can only rely on manual verification of the original documents. This is inefficient and easily affected by subjective factors. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain-based invoice compliance verification 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] In a first aspect, the present invention provides a blockchain-based method for verifying the compliance of invoices, comprising:

[0007] Based on the business data of the issuer and the payee, a topology network is constructed; the core elements of the issuer's bill are extracted, the hash of the original elements is calculated, and the issuer's signature is combined to generate the issue hash, and the bill base topology data packet is output.

[0008] Extract the bill receiving request data from the bill recipient, record the request node information, verify the data format compliance by associating it with the bill baseline topology data package, and output the topology data package to be verified; call the original element hash, calculate the element hash to be verified and compare its consistency, and output the element hash consistency verification result.

[0009] When the hashes match, collect the hash values ​​of all tickets, filter suspected collision groups, distinguish collision types based on topology network rules, and output a hash collision determination report; when the hashes do not match, locate the tampered field, calculate the bit difference value, and output a tampered field analysis report.

[0010] When a genuine collision is identified, the true elements of the ticket are deduced based on the topology network, and a confirmation of the ticket's true status is generated; the output content is integrated, the abnormal operation status is determined, and processing is performed.

[0011] In conjunction with the first aspect, in the first implementation of the first aspect of this application, the step of constructing a topology network based on the business data of the ticket issuer and the ticket recipient includes:

[0012] Collect business data from the issuing party, including issuing party inventory data, historical invoice data, and inventory preparation cycle data; collect business data from the receiving party, including receiving party inventory data, inventory indicator data, and warehousing cycle data; set up core business nodes, including issuing party current inventory sub-node, issuing party historical inventory sub-node, receiving party current inventory sub-node, receiving party historical inventory sub-node, receiving party inventory indicator node, historical invoice set sub-node, and current invoice node; set up verification and association nodes, including hash verification node, inventory balancing node, and business rule node;

[0013] Construct topological edge association rules, where the edge rule between the issuer's historical inventory sub-node and the historical bill set sub-node is that the issuer's inventory decrease equals the corresponding bill shipment volume; the edge rule between the recipient's historical inventory sub-node and the historical bill set sub-node is that the recipient's inventory increase equals the corresponding bill shipment volume; the edge rule between the current bill node and the inventory balance node is that the issuer's inventory decrease equals the recipient's inventory increase; and the edge rule between the current bill node and the business rule node is that the shipment volume is less than or equal to the recipient's inventory index, the unit price is within the issuer's historical shipment unit price range, and the amount equals the product of the shipment volume and the unit price.

[0014] A core closed loop is formed, including the issuer's inventory change closed loop, the payee's inventory change closed loop, the bill element verification closed loop, and the hash association closed loop, constructing a topology network. Specifically, the issuer's inventory change closed loop sequentially associates the issuer's historical inventory sub-nodes, historical bill set sub-nodes, and the issuer's current inventory sub-nodes; the payee's inventory change closed loop sequentially associates the payee's historical inventory sub-nodes, historical bill set sub-nodes, and the payee's current inventory sub-nodes; the bill element verification closed loop sequentially associates the historical bill set sub-nodes, business rule nodes, and the current bill node; and the hash association closed loop sequentially associates the historical bill set sub-nodes, hash verification nodes, and the current bill node. The topology edge association rules and the core closed loop constitute the topology network rules.

[0015] In conjunction with the first aspect, in the second implementation of the first aspect of this application, the step of extracting the core elements of the bill from the issuer, calculating the original element hash, generating a bill issuance hash by combining the issuer's signature, and outputting the bill baseline topology data packet includes:

[0016] Extract the core elements of the invoice submitted by the issuer, including invoice number, quantity shipped, unit price, amount, shipping date, issuer's name, and recipient's name; and standardize the format of the core elements of the invoice.

[0017] The core elements of the standardized bill are hashed using the SHA256 hash algorithm to obtain the original element hash. The original element hash is digitally signed using the issuer's on-chain private key to generate the issuer's digital signature. The original element hash and the issuer's digital signature are combined to generate the issue hash, specifically by concatenating the original element hash, separator, and issuer's digital signature in the format, and then calculating the issue hash using the SHA256 hash algorithm.

[0018] Integrate topology network data, raw element hashes, and ticket hashes to generate and output a ticket baseline topology data package.

[0019] In conjunction with the first aspect, in the third implementation of the first aspect of this application, the step of extracting the bill receiving request data of the bill recipient, recording the request node information, verifying the compliance of the data format by associating the bill reference topology data packet, and outputting the topology data packet to be verified includes:

[0020] Extract the bill receipt request data initiated by the bill recipient, including the bill number, the elements to be verified, and the bill recipient's digital signature; among which, the elements to be verified correspond to the core elements of the bill issued by the issuer, including the bill number, shipment quantity, unit price, amount, shipment date, issuer name, and bill recipient name; record the request node information, including the request device identifier and request timestamp;

[0021] The reference bill baseline topology data package is associated, and the preset standardized format rules are extracted to verify whether the data type and format of the elements to be verified are compliant.

[0022] Once the verification passes, the system integrates the invoice receipt request data, request node information, and compliant elements to be verified, adds a format verification pass flag, and generates and outputs the topology data package to be verified. If the verification fails, a format error message is returned, and the receiving party corrects the error as prompted and re-initiates the invoice receipt request, and the format verification is performed again.

[0023] In conjunction with the first aspect, in the fourth implementation of the first aspect of this application, the step of calling the original element hash, calculating the element hash to be verified and comparing its consistency, and outputting the element hash consistency verification result includes:

[0024] The original element hash stored in the bill base topology data package is called, and the compliant elements to be verified in the topology data package to be verified are extracted and processed according to the standardized format rules consistent with those used in the calculation of the original element hash.

[0025] The SHA256 hash algorithm is used to perform hash calculations on the standardized elements to be verified, resulting in a hash of the element to be verified. The hash of the element to be verified is then compared bit by bit with the original element hash to determine whether the byte sequences of the two elements match completely. When the byte sequences match completely, the output element hash consistency verification result is "consistent," accompanied by the original element hash, the hash of the element to be verified, and a description of the matching result. When any byte does not match, the output element hash consistency verification result is "inconsistent," accompanied by the specific content of the original element hash and the hash of the element to be verified, and a hint of the difference, and the output element hash consistency verification result is "inconsistent."

[0026] In conjunction with the first aspect, in the fifth implementation of the first aspect of this application, when the hashes are consistent, the hash values ​​of all tickets are collected, suspected collision groups are filtered, collision types are distinguished based on topology network rules, and a hash collision determination report is output, including:

[0027] When the consistency verification result of the element hash is consistent, the original element hashes corresponding to all historical tickets stored in the consortium chain and the element hashes to be verified are collected to form a complete set of ticket hashes.

[0028] Using the hash of the element to be verified as the retrieval benchmark, select all the bills that completely match the hash from the full set of bill hashes, form a suspected collision group, and record the bill number, associated issuer information, payee information and corresponding element data of each bill in each group;

[0029] The topological edge association rules and core closed loop constructed in the topological network are invoked to perform multi-dimensional verification on all invoices in suspected collision groups. This includes verifying the consistency of inventory changes, the compliance of element logic, and the rationality of timing. Specifically, verifying the consistency of inventory changes involves checking whether the decrease in inventory of the issuing party and the increase in inventory of the receiving party for each group of invoices match the shipment volume of their respective invoices, and ensuring that there are no conflicts in the inventory change logic of different invoices within the group. Verifying the compliance of element logic involves checking whether the shipment volume, unit price, and amount of each group of invoices meet the logical calculation relationship of the amount, and whether the shipment volume is less than or equal to the receiving party's inventory indicator and the unit price is within the range of the issuing party's historical shipment unit price. Verifying the rationality of timing involves checking whether the timing relationship between the shipment date of each group of invoices and the issuing party's preparation completion time and the receiving party's warehousing time conforms to the topological network rules.

[0030] Based on the verification results, the collision type is distinguished. When the element data of all tickets in the suspected collision group are completely consistent, and the inventory changes, element logic and time series all conform to the topology network rules, it is determined to be a false collision. When the element data of tickets in the suspected collision group are inconsistent, or there are conflicts in the inventory changes, element logic and time series, it is determined to be a real collision.

[0031] Generate a hash collision determination report, including the composition of suspected collision groups, multi-dimensional verification details, collision type determination results, and determination basis.

[0032] In conjunction with the first aspect, in the sixth implementation of the first aspect of this application, the step of locating the tampered field, calculating the bit difference value, and outputting a tampered field analysis report when the hashes are inconsistent includes:

[0033] When the element hash consistency verification result is inconsistent, the original core elements of the bill are extracted from the bill base topology data package, and the elements to be verified are extracted from the topology data package to be verified, to ensure that the field types and arrangement order of the two sets of elements are completely consistent.

[0034] The original elements and the elements to be verified are compared field by field. The comparison includes the data content, format specifications and arrangement order of each field. Fields with mismatched content are identified as tampered fields. The specific comparison fields include invoice number, shipment quantity, unit price, amount, shipment date, invoice issuer name and invoice recipient name.

[0035] Extract the original element hash and the element hash to be verified, convert them into binary bit sequences respectively, compare the two binary bit sequences bit by bit, count the number of bits with different values ​​at corresponding positions as the bit difference value, and record the specific value of the bit difference value and the position distribution of the difference bits.

[0036] Generate a tampered field analysis report, including the source of the original element, the source of the element to be verified, the details of the field-by-field comparison, the specific information of the tampered field, the bit difference value and calculation process, and the distribution of the difference bit positions.

[0037] In conjunction with the first aspect, in the seventh implementation of the first aspect of this application, the step of generating a confirmation of the true status of a ticket by deriving the true elements of the ticket based on the topology network when a genuine collision is determined includes:

[0038] When the collision type is determined to be a real collision, the core closed loop and topological edge association rules of the topological network are invoked to extract the element data, issuer inventory data, recipient inventory data, time series data and historical ticket verification records corresponding to all tickets in the suspected collision group;

[0039] Based on the closed-loop verification of the issuer's inventory changes, the matching relationship between the issuer's historical inventory reduction and historical invoice delivery volume is used to filter out delivery volume data consistent with the inventory change logic and determine it as the actual delivery volume. Based on the closed-loop verification of the recipient's inventory changes, the accuracy of the actual delivery volume is cross-verified by combining the recipient's historical inventory increase and warehousing and acceptance records to ensure that the recipient's inventory changes match the actual delivery volume. Based on the closed-loop verification of invoice elements, the logical calculation relationship of the issuer's historical delivery unit price range and amount is referenced to deduce the actual unit price that conforms to the business specifications and calculate the actual amount. Combining the time-series association rules of the topology network, the time of the issuer's preparation completion and the time of the recipient's warehousing are checked to determine the actual delivery date that conforms to the time-series logic.

[0040] Integrate the actual shipment volume, actual unit price, actual amount, actual shipment date, invoice number, name of the issuer, and name of the recipient to form the true elements of the invoice;

[0041] The true elements of the bill are synchronized to the on-chain nodes of the issuer and the payee. After obtaining confirmation feedback from both parties, a bill authenticity status confirmation form is generated, including the suspected collision group identifier, details of the true elements of the bill, the reasoning basis, and the confirmation status of both parties.

[0042] In conjunction with the first aspect, in the eighth implementation of the first aspect of this application, the process of integrating the output content, determining the abnormal operation state, and handling it includes:

[0043] Integrate all outputs from the entire process, including element hash consistency verification results, hash collision determination reports, tampered field analysis reports, true elements of the invoice, confirmation of the true status of the invoice, and format verification records, to form a complete set of verification information;

[0044] Based on the full set of verification information, the abnormal operation status is classified and determined. When the element hash consistency verification result is inconsistent and there is a clearly tampered field, it is determined to be an abnormality of document element tampering; when the collision type is determined to be a real collision, it is determined to be an abnormality of document information conflict; when the collision type is determined to be a pseudo collision, it is determined to be an abnormality of duplicate request operation; when the format verification fails and no topology data packet to be verified is generated, it is determined to be an abnormality of data format submission.

[0045] For anomalies related to tampering of bill elements, the analysis report of tampered fields is synchronized to the consortium blockchain regulatory node and the issuer, triggering on-chain evidence storage to retain tampering traces, and pushing tampering warnings and element correction prompts to the payee; for anomalies related to bill information conflicts, a bill authenticity confirmation form is distributed to the issuer and payee, and the on-chain bill information is updated after both parties confirm, marking the conflicting bill status as verified and corrected; for anomalies related to duplicate request operations, the payee's current bill receipt request is rejected, a duplicate request prompt is returned, the request node information is recorded, and duplicate submissions to the same node are restricted within a short period of time; for anomalies related to data format submission, the bill recipient is provided with details of format verification and standardized format requirements, allowing them to correct according to the specifications and re-initiate the bill receipt request;

[0046] Generate an exception handling log to record the exception type, judgment basis, handling measures, execution results, and related node information.

[0047] Secondly, the present invention provides a blockchain-based invoice compliance verification system, comprising:

[0048] The topology network construction module includes a business data acquisition unit, a node configuration unit, a topology edge rule definition unit, and a core closed-loop construction unit. The business data acquisition unit collects business data; the node configuration unit sets up core business nodes and verifies associated nodes; the topology edge rule definition unit defines the association logic rules between topology edges of each node; and the core closed-loop construction unit builds the core closed loop, forming a complete topology network rule set.

[0049] The bill reference data generation module includes a bill element extraction unit, a hash calculation and signature unit, and a reference data package integration unit. The bill element extraction unit extracts the core elements of the bill submitted by the issuer and completes the standardized format processing. The hash calculation and signature unit calculates the hash of the original elements, completes the digital signature, and generates the issue hash. The reference data package integration unit integrates the topology network data, the original element hash, and the issue hash to generate and output the bill reference topology data package.

[0050] The request receiving and format verification module includes a request data extraction unit, a format compliance verification unit, and a data packet generation unit. The request data extraction unit extracts the bill receiving request data and request node information from the bill recipient. The format compliance verification unit associates the format rules of the bill baseline topology data packet with the data to be verified to check the data type and format compliance of the elements to be verified. The data packet generation unit integrates the request data to generate the topology data packet to be verified after successful verification; if verification fails, it returns an error message and guides correction.

[0051] The hash collision analysis and true element derivation module includes a hash consistency verification unit, a collision group collection and judgment unit, and a true element derivation and confirmation unit. The hash consistency verification unit compares the consistency of the original element hash with the hash of the element to be verified, outputting the verification result and a difference prompt. The collision group collection and judgment unit collects the original element hashes of historical invoices and the hashes of the current element to be verified, filters suspected collision groups, and distinguishes between false collisions and true collisions based on topology network rules. The true element derivation and confirmation unit extracts relevant data within suspected collision groups, derives the true elements of the invoice based on topology network rules, and generates a confirmation slip for the true status of the invoice.

[0052] The end-to-end exception handling module includes an exception status determination unit, an exception handling execution unit, and an exception ledger management unit. The exception status determination unit integrates the output content of the entire process and classifies and determines the exception type. The exception handling execution unit executes handling measures for different exception types. The exception ledger management unit records the exception type, determination basis, handling measures, and execution results, and generates and maintains the exception handling ledger.

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

[0054] 1. This invention performs hash collision determination under the condition of hash consistency, and performs multi-dimensional verification in combination with topology network rules to distinguish between false collisions and real collisions.

[0055] 2. The present invention designs a tampering tracing mechanism when hash inconsistency occurs. It locates the tampered field by comparing each field, calculates the bit difference value, and generates an analysis report.

[0056] 3. In real collision scenarios, this invention invokes topological network rules and combines multi-dimensional cross-validation to deduce real elements. Attached Figure Description

[0057] Figure 1 This is a schematic diagram illustrating the steps of a blockchain-based bill compliance verification method according to the present invention.

[0058] Figure 2 This is a system architecture diagram of a blockchain-based invoice compliance verification system according to the present invention. Detailed Implementation

[0059] 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.

[0060] Example: Figures 1-2As shown, the present invention provides a technical solution.

[0061] like Figure 1 A schematic diagram illustrating the steps of a blockchain-based bill compliance verification method is provided. This invention offers a blockchain-based bill compliance verification method, comprising:

[0062] Step S100: Construct a topology network based on the business data of the issuer and the payee; extract the core elements of the issuer's bill, calculate the hash of the original elements, generate the bill issuance hash by combining the issuer's signature, and output the bill base topology data packet.

[0063] Specifically, the system collects business data from the issuing party, including issuing party inventory data, historical invoice data, and inventory preparation cycle data; it also collects business data from the receiving party, including receiving party inventory data, inventory indicator data, and warehousing cycle data; it sets up core business nodes, including the issuing party's current inventory sub-node, the issuing party's historical inventory sub-node, the receiving party's current inventory sub-node, the receiving party's historical inventory sub-node, the receiving party's inventory indicator node, the historical invoice set sub-node, and the current invoice node; and it sets up verification and association nodes, including hash verification nodes, inventory balancing nodes, and business rule nodes.

[0064] Construct topological edge association rules, where the edge rule between the issuer's historical inventory sub-node and the historical bill set sub-node is that the issuer's inventory decrease equals the corresponding bill shipment volume; the edge rule between the recipient's historical inventory sub-node and the historical bill set sub-node is that the recipient's inventory increase equals the corresponding bill shipment volume; the edge rule between the current bill node and the inventory balance node is that the issuer's inventory decrease equals the recipient's inventory increase; and the edge rule between the current bill node and the business rule node is that the shipment volume is less than or equal to the recipient's inventory index, the unit price is within the issuer's historical shipment unit price range, and the amount equals the product of the shipment volume and the unit price.

[0065] A core closed loop is formed, including the issuer's inventory change closed loop, the payee's inventory change closed loop, the bill element verification closed loop, and the hash association closed loop, constructing a topology network. Specifically, the issuer's inventory change closed loop sequentially associates the issuer's historical inventory sub-nodes, historical bill set sub-nodes, and the issuer's current inventory sub-nodes; the payee's inventory change closed loop sequentially associates the payee's historical inventory sub-nodes, historical bill set sub-nodes, and the payee's current inventory sub-nodes; the bill element verification closed loop sequentially associates the historical bill set sub-nodes, business rule nodes, and the current bill node; and the hash association closed loop sequentially associates the historical bill set sub-nodes, hash verification nodes, and the current bill node. The topology edge association rules and the core closed loop constitute the topology network rules.

[0066] Extract the core elements of the invoice submitted by the issuer, including invoice number, quantity shipped, unit price, amount, shipping date, issuer's name, and recipient's name; and standardize the format of the core elements of the invoice.

[0067] The core elements of the standardized bill are hashed using the SHA256 hash algorithm to obtain the original element hash. The original element hash is digitally signed using the issuer's on-chain private key to generate the issuer's digital signature. The original element hash and the issuer's digital signature are combined to generate the issue hash, specifically by concatenating the original element hash, separator, and issuer's digital signature in the format, and then calculating the issue hash using the SHA256 hash algorithm.

[0068] Integrate topology network data, raw element hashes, and ticket hashes to generate and output a ticket baseline topology data package.

[0069] In one specific embodiment, the issuing party's inventory data includes an initial inventory of 1000 units, historical invoice data containing 5 shipment records totaling 500 units, and a preparation cycle of 7 days. The receiving party's inventory data includes a current inventory of 800 units, an inventory target of 600 units, and an inbound cycle of 3 days. After setting core business nodes and verification related nodes, topological edge association rules are constructed. The edge rule between the issuing party's historical inventory sub-node and the historical invoice set sub-node is that the inventory reduction matches the corresponding invoice shipment volume. The receiving party's corresponding edge rule is similar. The edge rule between the current invoice node and the inventory balance node is that the issuing party's inventory reduction equals the receiving party's inventory increase. The edge rule between the business rule node and the business rule node is that the shipment volume does not exceed 600 units, the unit price is within the issuing party's historical shipment unit price range of 80-120 yuan, and the amount equals the product of the shipment volume and the unit price. This forms the construction of four core closed loops. The topology network is used to extract the core elements of the bill submitted by the issuer: bill number JP20250601001, quantity of shipment 500 pieces, unit price 100 yuan, amount 50,000 yuan, shipment date June 1, 2025, issuer name Company A, and payee name Company B. After standardization, the original element hash a1b2c3d4e5f67890abcdef is calculated using the SHA256 algorithm. A digital signature s8f7d6e5r4t3y2u1i0 is generated by signing with the issuer's on-chain private key. The original element hash, separator, and digital signature are concatenated and the bill hash x9y8z7w6v5u4t3s2d1 is calculated again using the SHA256 algorithm. Finally, the topology network data, the original element hash, and the bill hash are integrated to generate the bill base topology data package and output.

[0070] Step S200: Extract the bill receiving request data from the bill recipient, record the request node information, verify the data format compliance by associating it with the bill baseline topology data packet, and output the topology data packet to be verified; call the original element hash, calculate the element hash to be verified and compare its consistency, and output the element hash consistency verification result.

[0071] Specifically, the system extracts the bill receiving request data initiated by the bill recipient, including the bill number, the elements to be verified, and the bill recipient's digital signature. Among them, the elements to be verified correspond to the core elements of the bill issued by the issuer, including the bill number, shipment quantity, unit price, amount, shipment date, issuer name, and bill recipient name. The system also records the request node information, including the request device identifier and the request timestamp.

[0072] The reference bill baseline topology data package is associated, and the preset standardized format rules are extracted to verify whether the data type and format of the elements to be verified are compliant.

[0073] Once the verification passes, the system integrates the invoice receipt request data, request node information, and compliant elements to be verified, adds a format verification pass flag, and generates and outputs the topology data package to be verified. If the verification fails, a format error message is returned, and the receiving party corrects the error as prompted and re-initiates the invoice receipt request, and the format verification is performed again.

[0074] The original element hash stored in the bill base topology data package is called, and the compliant elements to be verified in the topology data package to be verified are extracted and processed according to the standardized format rules consistent with those used in the calculation of the original element hash.

[0075] The SHA256 hash algorithm is used to perform hash calculations on the standardized elements to be verified, resulting in a hash of the element to be verified. The hash of the element to be verified is then compared bit by bit with the original element hash to determine whether the byte sequences of the two elements match completely. When the byte sequences match completely, the output element hash consistency verification result is "consistent," accompanied by the original element hash, the hash of the element to be verified, and a description of the matching result. When any byte does not match, the output element hash consistency verification result is "inconsistent," accompanied by the specific content of the original element hash and the hash of the element to be verified, and a hint of the difference, and the output element hash consistency verification result is "inconsistent."

[0076] In one specific embodiment, the bill receiving request data initiated by the receiving company, Company B, is extracted. This data includes the bill number JP20250601001, the quantity of goods shipped (500 pieces), unit price (100 yuan), amount (50,000 yuan), shipping date (June 1, 2025), issuing company name (Company A), receiving company name (Company B), and receiving company digital signature (s1d2f3g4h5j6k7l8). The request node information is recorded as the request device identifier SN2025001 and the request timestamp 20250601103000. The data is then linked to the bill baseline topology data package to extract preset standardized format rules. Verification is performed to ensure compliance with the following elements: date format (YYYY year MM month DD day), amount (integer), and unit price (two decimal places). The bill receiving request data, request node information, and... After compliance, the elements to be verified are marked with a format verification pass flag, and a topology data package to be verified is generated and output. The original element hash a1b2c3d4e5f67890abcdef stored in the bill base topology data package is called to extract the compliant elements to be verified from the topology data package to be verified. The elements to be verified are processed according to the standardized format rules consistent with those used in the original element hash calculation. The SHA256 algorithm is used to perform hash calculation on the standardized elements to be verified to obtain the hash a1b2c3d4e5f67890abcdef. The hash of the elements to be verified is compared bit by bit with the hash of the original element. If the byte sequences of the two are completely matched, the element hash consistency verification result is output as consistent, along with the original element hash, the hash of the elements to be verified, and a description of the matching result.

[0077] Step S300: When the hashes match, collect the hash values ​​of all tickets, filter suspected collision groups, distinguish collision types based on topology network rules, and output a hash collision determination report; when the hashes do not match, locate the tampered field, calculate the bit difference value, and output a tampered field analysis report.

[0078] Specifically, when the consistency verification result of the element hash is consistent, the original element hashes corresponding to all historical tickets already stored in the consortium chain, as well as the element hashes to be verified now, are collected to form a complete set of ticket hashes.

[0079] Using the hash of the element to be verified as the retrieval benchmark, select all the bills that completely match the hash from the full set of bill hashes, form a suspected collision group, and record the bill number, associated issuer information, payee information and corresponding element data of each bill in each group;

[0080] The topological edge association rules and core closed loop constructed in the topological network are invoked to perform multi-dimensional verification on all invoices in suspected collision groups. This includes verifying the consistency of inventory changes, the compliance of element logic, and the rationality of timing. Specifically, verifying the consistency of inventory changes involves checking whether the decrease in inventory of the issuing party and the increase in inventory of the receiving party for each group of invoices match the shipment volume of their respective invoices, and ensuring that there are no conflicts in the inventory change logic of different invoices within the group. Verifying the compliance of element logic involves checking whether the shipment volume, unit price, and amount of each group of invoices meet the logical calculation relationship of the amount, and whether the shipment volume is less than or equal to the receiving party's inventory indicator and the unit price is within the range of the issuing party's historical shipment unit price. Verifying the rationality of timing involves checking whether the timing relationship between the shipment date of each group of invoices and the issuing party's preparation completion time and the receiving party's warehousing time conforms to the topological network rules.

[0081] Based on the verification results, the collision type is distinguished. When the element data of all tickets in the suspected collision group are completely consistent, and the inventory changes, element logic and time series all conform to the topology network rules, it is determined to be a false collision. When the element data of tickets in the suspected collision group are inconsistent, or there are conflicts in the inventory changes, element logic and time series, it is determined to be a real collision.

[0082] Generate a hash collision determination report, including the composition of suspected collision groups, multi-dimensional verification details, collision type determination results, and determination basis.

[0083] When the element hash consistency verification result is inconsistent, the original core elements of the bill are extracted from the bill base topology data package, and the elements to be verified are extracted from the topology data package to be verified, to ensure that the field types and arrangement order of the two sets of elements are completely consistent.

[0084] The original elements and the elements to be verified are compared field by field. The comparison includes the data content, format specifications and arrangement order of each field. Fields with mismatched content are identified as tampered fields. The specific comparison fields include invoice number, shipment quantity, unit price, amount, shipment date, invoice issuer name and invoice recipient name.

[0085] Extract the original element hash and the element hash to be verified, convert them into binary bit sequences respectively, compare the two binary bit sequences bit by bit, count the number of bits with different values ​​at corresponding positions as the bit difference value, and record the specific value of the bit difference value and the position distribution of the difference bits.

[0086] Generate a tampered field analysis report, including the source of the original element, the source of the element to be verified, the details of the field-by-field comparison, the specific information of the tampered field, the bit difference value and calculation process, and the distribution of the difference bit positions.

[0087] In one specific embodiment, when the element hash consistency verification result is consistent, the original element hashes corresponding to the three historical tickets already stored in the consortium blockchain are aggregated, along with the currently unverified element hash a1b2c3d4e5f67890abcdef, to form a complete set of ticket hashes. Using the currently unverified element hash as the retrieval benchmark, historical ticket number JP20250601001 is selected as a suspected collision group because its hash completely matches that of the current ticket number JP20250601001. Both sets of invoices are associated with Company A, the issuer, and Company B, the recipient. The data for both sets includes a shipment volume of 500 units, a unit price of 100 yuan, and a total amount of 50,000 yuan. Multi-dimensional validation using topology network rules is performed. Inventory change consistency checks show that the issuer's inventory decreased by 500 units in both instances, while the recipient's increased by 500 units in both instances, matching the shipment volume without conflict. Element logic compliance checks show that the shipment volume of 500 units is ≤ the recipient's inventory of 600 units, the unit price of 100 yuan is within the issuer's historical shipment unit price range of 80-120 yuan, and the total amount... The amount equals the product of the shipment quantity and the unit price. The timeline rationality check shows that both shipment dates are June 1, 2025; the invoice issuer's goods preparation completion time is May 30, 2025; and the invoice recipient's warehousing time is June 3, 2025. All these conform to the timeline rules, thus it is determined to be a false collision, and a hash collision determination report is generated. When the element hash consistency check result is inconsistent, the original core elements of the invoice are extracted from the invoice baseline topology data package, and the elements to be verified are extracted from the topology data package to be verified. A field-by-field comparison reveals that the shipment in the elements to be verified... The quantity is 600 pieces and the amount is 60,000 yuan, which does not match the original elements of 500 pieces and 50,000 yuan. It is determined that the quantity and amount are tampered fields. The hashes of the original elements a1b2c3d4e5f67890abcdef and the hashes of the elements to be verified a1b2c3d4e5f67890abcedf are extracted, converted into binary bit sequences, and compared bit by bit. The bit difference value is 8, and the difference bit positions are distributed from the 32nd to the 39th bit. A tampered field analysis report is generated.

[0088] Step S400: When a real collision is determined, deduce the real elements of the ticket based on the topology network and generate a ticket real status confirmation form;

[0089] Specifically, when the collision type is determined to be a real collision, the core closed loop and topological edge association rules of the topological network are invoked to extract the element data, issuer inventory data, recipient inventory data, time series data and historical ticket verification records corresponding to all tickets in the suspected collision group.

[0090] Based on the closed-loop verification of the issuer's inventory changes, the matching relationship between the issuer's historical inventory reduction and historical invoice delivery volume is used to filter out delivery volume data consistent with the inventory change logic and determine it as the actual delivery volume. Based on the closed-loop verification of the recipient's inventory changes, the accuracy of the actual delivery volume is cross-verified by combining the recipient's historical inventory increase and warehousing and acceptance records to ensure that the recipient's inventory changes match the actual delivery volume. Based on the closed-loop verification of invoice elements, the logical calculation relationship of the issuer's historical delivery unit price range and amount is referenced to deduce the actual unit price that conforms to the business specifications and calculate the actual amount. Combining the time-series association rules of the topology network, the time of the issuer's preparation completion and the time of the recipient's warehousing are checked to determine the actual delivery date that conforms to the time-series logic.

[0091] Integrate the actual shipment volume, actual unit price, actual amount, actual shipment date, invoice number, name of the issuer, and name of the recipient to form the true elements of the invoice;

[0092] The true elements of the bill are synchronized to the on-chain nodes of the issuer and the payee. After obtaining confirmation feedback from both parties, a bill authenticity status confirmation form is generated, including the suspected collision group identifier, details of the true elements of the bill, the reasoning basis, and the confirmation status of both parties.

[0093] In one specific embodiment, when a genuine collision is determined, the core closed-loop and topological edge association rules of the topological network are invoked to extract the element data of two invoices within the suspected collision group. The issuer is Company A, the recipient is Company B, and both invoice numbers are JP20250601001. However, one invoice has a shipment quantity of 500 units, a unit price of 100 yuan, and a total amount of 50,000 yuan, while the other has a shipment quantity of 600 units, a unit price of 110 yuan, and a total amount of 66,000 yuan. Simultaneously, the issuer's inventory data is extracted: initial 1,000 units, with a historical decrease of 500 units; the recipient's inventory data is extracted: initial 800 units, with a historical increase of 500 units; the time-series data includes the issuer's inventory preparation completion time (May 30, 2025) and the recipient's warehousing time (June 3, 2025), as well as historical invoice verification records. Based on the closed-loop verification of the issuer's inventory changes, the issuer's historical inventory decrease of 500 units matches the historical invoice shipment quantity, thus identifying the genuine shipment quantity as 500 units. The receiving party's inventory increased by 500 units, and the warehousing and acceptance records were cross-verified to confirm the actual shipment volume. Based on the closed-loop verification of invoice elements, and referring to the historical shipment unit price range of 80-120 yuan from the issuing party, the actual unit price was deduced to be 100 yuan, and the actual amount was calculated to be 50,000 yuan. Combining the time-series association rules, the preparation completion time and warehousing time were checked, and the actual shipment date was determined to be June 1, 2025. The actual shipment volume of 500 units, the actual unit price of 100 yuan, the actual amount of 50,000 yuan, the actual shipment date of June 1, 2025, the invoice number JP20250601001, the issuing party Company A, and the receiving party Company B were integrated to form the true elements of the invoice. This was synchronized to the on-chain nodes of Company A and Company B, and after obtaining confirmation feedback from both parties, a confirmation form for the true status of the invoice was generated, including the suspected collision group identifier CP20250601001, details of the true elements of the invoice, the derivation basis, and the confirmed status by both parties.

[0094] Step S500: Integrate the output content, determine the abnormal operation status, and handle it.

[0095] Specifically, the entire process output is integrated, including element hash consistency verification results, hash collision judgment reports, tampering field analysis reports, true elements of the invoice, confirmation of the true status of the invoice, and format verification records, forming a complete set of verification information;

[0096] Based on the full set of verification information, the abnormal operation status is classified and determined. When the element hash consistency verification result is inconsistent and there is a clearly tampered field, it is determined to be an abnormality of document element tampering; when the collision type is determined to be a real collision, it is determined to be an abnormality of document information conflict; when the collision type is determined to be a pseudo collision, it is determined to be an abnormality of duplicate request operation; when the format verification fails and no topology data packet to be verified is generated, it is determined to be an abnormality of data format submission.

[0097] For anomalies related to tampering of bill elements, the analysis report of tampered fields is synchronized to the consortium blockchain regulatory node and the issuer, triggering on-chain evidence storage to retain tampering traces, and pushing tampering warnings and element correction prompts to the payee; for anomalies related to bill information conflicts, a bill authenticity confirmation form is distributed to the issuer and payee, and the on-chain bill information is updated after both parties confirm, marking the conflicting bill status as verified and corrected; for anomalies related to duplicate request operations, the payee's current bill receipt request is rejected, a duplicate request prompt is returned, the request node information is recorded, and duplicate submissions to the same node are restricted within a short period of time; for anomalies related to data format submission, the bill recipient is provided with details of format verification and standardized format requirements, allowing them to correct according to the specifications and re-initiate the bill receipt request;

[0098] Generate an exception handling log to record the exception type, judgment basis, handling measures, execution results, and related node information.

[0099] In one specific embodiment, the entire process output is integrated, including the element hash consistency verification result, hash collision judgment report, tampered field analysis report, true elements of the invoice, confirmation of the true status of the invoice, and format verification record, forming a complete set of verification information. Based on this set, abnormal states are classified and judged. For example, an invoice receiving request initiated by the receiving company (Company B) is judged as an invoice element tampering anomaly because the quantity of goods shipped (600 pieces) and the amount of RMB 66,000 are inconsistent with the original elements, the hash verification is inconsistent, and the quantity and amount are identified as tampered fields. Another invoice is judged as an invoice information conflict anomaly because the hash is consistent but the element data conflicts. Another invoice is judged as a duplicate request anomaly because the hash is consistent and the element inventory time sequence is compliant. Yet another request is judged as a data format submission anomaly because the shipping date format is incorrect and no topology data packet to be verified is generated. For invoice element tampering anomalies, the tampered field analysis report is synchronized to the consortium blockchain supervision. The node and the issuing company A trigger on-chain evidence storage to retain tampering traces, pushes tampering warnings and element correction prompts to company B, and distributes a confirmation of the true status of the bill to companies A and B for bill information conflicts. After both parties confirm, the on-chain bill information is updated, and the conflicting bill status is marked as verified and corrected. For duplicate request operations, the current request from the receiving party is rejected, a duplicate request prompt is returned, the requesting device identifier SN2025001 is recorded, and duplicate submissions to the same node are restricted for 1 hour. For data format submission anomalies, the receiving party is informed that the date format must be YYYY year MM month DD day, etc., and is allowed to correct and re-initiate. Finally, an anomaly handling ledger is generated, recording the judgment basis, handling measures, and execution results of various anomalies. The execution result of the tampering anomaly is that the regulatory node has stored evidence and company B has received a warning. The associated node information includes the requesting device identifier SN2025001 and the regulatory node code JG2025001.

[0100] like Figure 2The system architecture diagram of a blockchain-based invoice compliance verification system is shown. This invention provides a blockchain-based invoice compliance verification system, comprising:

[0101] The topology network construction module includes a business data acquisition unit, a node configuration unit, a topology edge rule definition unit, and a core closed-loop construction unit. The business data acquisition unit collects business data; the node configuration unit sets up core business nodes and verifies associated nodes; the topology edge rule definition unit defines the association logic rules between topology edges of each node; and the core closed-loop construction unit builds the core closed loop, forming a complete topology network rule set.

[0102] The bill reference data generation module includes a bill element extraction unit, a hash calculation and signature unit, and a reference data package integration unit. The bill element extraction unit extracts the core elements of the bill submitted by the issuer and completes the standardized format processing. The hash calculation and signature unit calculates the hash of the original elements, completes the digital signature, and generates the issue hash. The reference data package integration unit integrates the topology network data, the original element hash, and the issue hash to generate and output the bill reference topology data package.

[0103] The request receiving and format verification module includes a request data extraction unit, a format compliance verification unit, and a data packet generation unit. The request data extraction unit extracts the bill receiving request data and request node information from the bill recipient. The format compliance verification unit associates the format rules of the bill baseline topology data packet with the data to be verified to check the data type and format compliance of the elements to be verified. The data packet generation unit integrates the request data to generate the topology data packet to be verified after successful verification; if verification fails, it returns an error message and guides correction.

[0104] The hash collision analysis and true element derivation module includes a hash consistency verification unit, a collision group collection and judgment unit, and a true element derivation and confirmation unit. The hash consistency verification unit compares the consistency of the original element hash with the hash of the element to be verified, outputting the verification result and a difference prompt. The collision group collection and judgment unit collects the original element hashes of historical invoices and the hashes of the current element to be verified, filters suspected collision groups, and distinguishes between false collisions and true collisions based on topology network rules. The true element derivation and confirmation unit extracts relevant data within suspected collision groups, derives the true elements of the invoice based on topology network rules, and generates a confirmation slip for the true status of the invoice.

[0105] The end-to-end exception handling module includes an exception status determination unit, an exception handling execution unit, and an exception ledger management unit. The exception status determination unit integrates the output content of the entire process and classifies and determines the exception type. The exception handling execution unit executes handling measures for different exception types. The exception ledger management unit records the exception type, determination basis, handling measures, and execution results, and generates and maintains the exception handling ledger.

[0106] 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 in all respects as exemplary and non-limiting, 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. A blockchain-based method for verifying the compliance of invoices, characterized in that, include: Based on the business data of the issuer and the payee, a topology network is constructed; the core elements of the issuer's bill are extracted, the original element hash is calculated, and the issue hash is generated by combining the issuer's signature; the bill base topology data package is output, specifically by concatenating the original element hash, separator, and issuer's digital signature in the format, and calculating the issue hash using the SHA256 hash algorithm; the topology network data, the original element hash, and the issue hash are integrated to generate and output the bill base topology data package. Extract the bill receiving request data from the bill recipient, record the request node information, verify the data format compliance by associating it with the bill benchmark topology data package, and output the topology data package to be verified. Specifically, associate it with the bill benchmark topology data package, extract the preset standardized format rules, and verify whether the data type and format of the elements to be verified are compliant. Once the verification is successful, the bill receiving request data, request node information, and compliant elements to be verified are integrated, a format verification pass flag is added, and a topology data package to be verified is generated and output. When the verification fails, a format error message is returned. The receiving party corrects the error message and re-initiates the invoice receipt request, and the format verification is performed again. The original element hash is called, the element hash to be verified is calculated and compared for consistency, and the element hash consistency verification result is output. Specifically, the original element hash stored in the bill benchmark topology data package is called, the compliant elements to be verified in the topology data package to be verified are extracted, and processed according to the standardized format rules consistent with those used in the calculation of the original element hash. The SHA256 hash algorithm is used to perform hash calculation on the standardized elements to be verified, resulting in a hash of the elements to be verified. The hash of the elements to be verified is then compared bit by bit with the original hash of the elements to determine whether the byte sequences of the two elements match completely. When the byte sequences match completely, the output hash consistency verification result is "matched", accompanied by the original hash, the hash of the elements to be verified, and a description of the matching result. When any byte does not match, the output hash consistency verification result is "inconsistent", accompanied by the specific content of the original hash and the hash of the elements to be verified, and a hint of the difference, and the output hash consistency verification result is "not matched". When the hashes are consistent, the hash values ​​of all the tickets are collected, and suspected collision groups are filtered out. Specifically, when the consistency verification result of the element hash is consistent, the original element hashes corresponding to all the historical tickets stored in the consortium chain and the element hashes to be verified are collected to form a complete set of ticket hashes. Using the hash of the element to be verified as the retrieval benchmark, select all the bills that completely match the hash from the full set of bill hashes, form a suspected collision group, and record the bill number, associated issuer information, payee information and corresponding element data of each bill in each suspected collision group; Based on the topology network rules, collision types are distinguished and a hash collision determination report is output. When hashes are inconsistent, the tampered field is located, the bit difference value is calculated, and a tampered field analysis report is output. When a genuine collision is identified, the true elements of the ticket are deduced based on the topology network, and a confirmation of the ticket's true status is generated; the output content is integrated, the abnormal operation status is determined, and processing is performed.

2. The blockchain-based bill compliance verification method according to claim 1, characterized in that, The step of constructing a topology network based on the business data of the ticket issuer and the ticket recipient includes: Collect business data from the issuing party, including issuing party inventory data, historical invoice data, and inventory preparation cycle data; collect business data from the receiving party, including receiving party inventory data, inventory indicator data, and warehousing cycle data; set up core business nodes, including issuing party current inventory sub-node, issuing party historical inventory sub-node, receiving party current inventory sub-node, receiving party historical inventory sub-node, receiving party inventory indicator node, historical invoice set sub-node, and current invoice node; set up verification and association nodes, including hash verification node, inventory balancing node, and business rule node; Construct topological edge association rules, where the edge rule between the issuer's historical inventory sub-node and the historical bill set sub-node is that the issuer's inventory decrease equals the corresponding bill shipment volume; the edge rule between the recipient's historical inventory sub-node and the historical bill set sub-node is that the recipient's inventory increase equals the corresponding bill shipment volume; the edge rule between the current bill node and the inventory balance node is that the issuer's inventory decrease equals the recipient's inventory increase; and the edge rule between the current bill node and the business rule node is that the shipment volume is less than or equal to the recipient's inventory index, the unit price is within the issuer's historical shipment unit price range, and the amount equals the product of the shipment volume and the unit price. A core closed loop is formed, including the issuer's inventory change closed loop, the payee's inventory change closed loop, the bill element verification closed loop, and the hash association closed loop, constructing a topology network. Specifically, the issuer's inventory change closed loop sequentially associates the issuer's historical inventory sub-nodes, historical bill set sub-nodes, and the issuer's current inventory sub-nodes; the payee's inventory change closed loop sequentially associates the payee's historical inventory sub-nodes, historical bill set sub-nodes, and the payee's current inventory sub-nodes; the bill element verification closed loop sequentially associates the historical bill set sub-nodes, business rule nodes, and the current bill node; and the hash association closed loop sequentially associates the historical bill set sub-nodes, hash verification nodes, and the current bill node. The topology edge association rules and the core closed loop constitute the topology network rules.

3. The blockchain-based bill compliance verification method according to claim 1, characterized in that, The process of extracting the core elements of the bill from the issuer, calculating the hash of the original elements, generating a bill issuance hash by combining the issuer's signature, and outputting the bill baseline topology data packet includes: Extract the core elements of the invoice submitted by the issuer, including invoice number, quantity shipped, unit price, amount, shipping date, issuer's name, and recipient's name; and standardize the format of the core elements of the invoice. The SHA256 hash algorithm is used to perform hash calculations on the core elements of the standardized bill to obtain the original element hash; the original element hash is digitally signed by the issuer's on-chain private key to generate the issuer's digital signature; the original element hash and the issuer's digital signature are combined to generate the issue hash.

4. The blockchain-based bill compliance verification method according to claim 1, characterized in that, The process involves extracting the bill receipt request data from the recipient, recording the request node information, verifying the data format compliance by associating it with the bill baseline topology data packet, and outputting the topology data packet to be verified, including: Extract the bill receipt request data initiated by the bill recipient, including the bill number, the elements to be verified, and the bill recipient's digital signature; among which, the elements to be verified correspond to the core elements of the bill issued by the issuer, including the bill number, shipment quantity, unit price, amount, shipment date, issuer name, and bill recipient name; record the request node information, including the request device identifier and request timestamp.

5. The method for verifying the compliance of invoices based on blockchain according to claim 1, characterized in that, When hashes match, the hash values ​​of all tickets are collected, suspected collision groups are filtered, collision types are distinguished based on topology network rules, and a hash collision determination report is output, including: The topological edge association rules and core closed loop constructed in the topological network are invoked to perform multi-dimensional verification on all invoices in suspected collision groups. This includes verifying the consistency of inventory changes, the compliance of element logic, and the rationality of timing. Specifically, verifying the consistency of inventory changes involves checking whether the decrease in inventory of the issuing party and the increase in inventory of the receiving party for each group of invoices match the shipment volume of their respective invoices, and ensuring that there are no conflicts in the inventory change logic of different invoices within the group. Verifying the compliance of element logic involves checking whether the shipment volume, unit price, and amount of each group of invoices meet the logical calculation relationship of the amount, and whether the shipment volume is less than or equal to the receiving party's inventory indicator and the unit price is within the range of the issuing party's historical shipment unit price. Verifying the rationality of timing involves checking whether the timing relationship between the shipment date of each group of invoices and the issuing party's preparation completion time and the receiving party's warehousing time conforms to the topological network rules. Based on the verification results, the collision type is distinguished. When the element data of all tickets in the suspected collision group are completely consistent, and the inventory changes, element logic and time series all conform to the topology network rules, it is determined to be a false collision. When the element data of tickets in the suspected collision group are inconsistent, or there are conflicts in the inventory changes, element logic and time series, it is determined to be a real collision. Generate a hash collision determination report, including the composition of suspected collision groups, multi-dimensional verification details, collision type determination results, and determination basis.

6. The blockchain-based bill compliance verification method according to claim 1, characterized in that, When hash inconsistencies occur, the process involves locating the tampered field, calculating the bit difference value, and outputting a tampered field analysis report, including: When the element hash consistency verification result is inconsistent, the original core elements of the bill are extracted from the bill base topology data package, and the elements to be verified are extracted from the topology data package to be verified, to ensure that the field types and arrangement order of the two sets of elements are completely consistent. The original elements and the elements to be verified are compared field by field. The comparison includes the data content, format specifications and arrangement order of each field. Fields with mismatched content are identified as tampered fields. The specific comparison fields include invoice number, shipment quantity, unit price, amount, shipment date, invoice issuer name and invoice recipient name. Extract the original element hash and the element hash to be verified, convert them into binary bit sequences respectively, compare the two binary bit sequences bit by bit, count the number of bits with different values ​​at corresponding positions as the bit difference value, and record the specific value of the bit difference value and the position distribution of the difference bits. Generate a tampered field analysis report, including the source of the original element, the source of the element to be verified, the details of the field-by-field comparison, the specific information of the tampered field, the bit difference value and calculation process, and the distribution of the difference bit positions.

7. The blockchain-based bill compliance verification method according to claim 1, characterized in that, When a collision is determined to be real, the document's true elements are deduced based on the topology network, and a document's true status confirmation is generated, including: When the collision type is determined to be a real collision, the core closed loop and topological edge association rules of the topological network are invoked to extract the element data, issuer inventory data, recipient inventory data, time series data and historical ticket verification records corresponding to all tickets in the suspected collision group; Based on the closed-loop verification of the issuer's inventory changes, the matching relationship between the issuer's historical inventory reduction and historical invoice delivery volume is used to filter out delivery volume data consistent with the inventory change logic and determine it as the actual delivery volume. Based on the closed-loop verification of the recipient's inventory changes, the accuracy of the actual delivery volume is cross-verified by combining the recipient's historical inventory increase and warehousing and acceptance records to ensure that the recipient's inventory changes match the actual delivery volume. Based on the closed-loop verification of invoice elements, the logical calculation relationship of the issuer's historical delivery unit price range and amount is referenced to deduce the actual unit price that conforms to the business specifications and calculate the actual amount. Combining the time-series association rules of the topology network, the time of the issuer's preparation completion and the time of the recipient's warehousing are checked to determine the actual delivery date that conforms to the time-series logic. Integrate the actual shipment volume, actual unit price, actual amount, actual shipment date, invoice number, name of the issuer, and name of the recipient to form the true elements of the invoice; The true elements of the bill are synchronized to the on-chain nodes of the issuer and the payee. After obtaining confirmation feedback from both parties, a bill authenticity status confirmation form is generated, including the suspected collision group identifier, details of the true elements of the bill, the reasoning basis, and the confirmation status of both parties.

8. The blockchain-based bill compliance verification method according to claim 1, characterized in that, The integrated output content is used to determine and process abnormal operation states, including: Integrate all outputs from the entire process, including element hash consistency verification results, hash collision determination reports, tampered field analysis reports, true elements of the invoice, confirmation of the true status of the invoice, and format verification records, to form a complete set of verification information; Based on the full set of verification information, the abnormal operation status is classified and determined. When the element hash consistency verification result is inconsistent and there is a clearly tampered field, it is determined to be an abnormality of document element tampering; when the collision type is determined to be a real collision, it is determined to be an abnormality of document information conflict; when the collision type is determined to be a pseudo collision, it is determined to be an abnormality of duplicate request operation; when the format verification fails and no topology data packet to be verified is generated, it is determined to be an abnormality of data format submission. For anomalies related to tampering of bill elements, the analysis report of tampered fields is synchronized to the consortium blockchain regulatory node and the issuer, triggering on-chain evidence storage to retain tampering traces, and pushing tampering warnings and element correction prompts to the payee; for anomalies related to bill information conflicts, a bill authenticity confirmation form is distributed to the issuer and payee, and the on-chain bill information is updated after both parties confirm, marking the conflicting bill status as verified and corrected; for anomalies related to duplicate request operations, the payee's current bill receipt request is rejected, a duplicate request prompt is returned, the request node information is recorded, and duplicate submissions to the same node are restricted within a short period of time; for anomalies related to data format submission, the bill recipient is provided with details of format verification and standardized format requirements, allowing them to correct according to the specifications and re-initiate the bill receipt request; Generate an exception handling log to record the exception type, judgment basis, handling measures, execution results, and related node information.

9. A blockchain-based invoice compliance verification system, using the blockchain-based invoice compliance verification method according to any one of claims 1-8, characterized in that, include: The topology network construction module includes a business data acquisition unit, a node configuration unit, a topology edge rule definition unit, and a core closed-loop construction unit. The business data acquisition unit collects business data; the node configuration unit sets up core business nodes and verifies associated nodes; the topology edge rule definition unit defines the association logic rules between topology edges of each node; and the core closed-loop construction unit builds the core closed loop, forming a complete topology network rule set. The bill reference data generation module includes a bill element extraction unit, a hash calculation and signature unit, and a reference data package integration unit. The bill element extraction unit extracts the core elements of the bill submitted by the issuer and completes the standardized format processing. The hash calculation and signature unit calculates the hash of the original elements, completes the digital signature, and generates the issue hash. The reference data package integration unit integrates the topology network data, the original element hash, and the issue hash to generate and output the bill reference topology data package. The request receiving and format verification module includes a request data extraction unit, a format compliance verification unit, and a data packet generation unit. The request data extraction unit extracts the bill receiving request data and request node information from the bill recipient. The format compliance verification unit associates the format rules of the bill baseline topology data packet with the data to be verified to check the data type and format compliance of the elements to be verified. The data packet generation unit integrates the request data to generate the topology data packet to be verified after successful verification; if verification fails, it returns an error message and guides correction. The hash collision analysis and true element derivation module includes a hash consistency verification unit, a collision group collection and judgment unit, and a true element derivation and confirmation unit. The hash consistency verification unit compares the consistency of the original element hash with the hash of the element to be verified, outputting the verification result and a difference prompt. The collision group collection and judgment unit collects the original element hashes of historical invoices and the hashes of the current element to be verified, filters suspected collision groups, and distinguishes between false collisions and true collisions based on topology network rules. The true element derivation and confirmation unit extracts relevant data within suspected collision groups, derives the true elements of the invoice based on topology network rules, and generates a confirmation slip for the true status of the invoice. The end-to-end exception handling module includes an exception status determination unit, an exception handling execution unit, and an exception ledger management unit. The exception status determination unit integrates the output content of the entire process and classifies and determines the exception type. The exception handling execution unit executes handling measures for different exception types. The exception ledger management unit records the exception type, determination basis, handling measures, and execution results, and generates and maintains the exception handling ledger.

Images