Invoice full-link automatic management and control system with anti-counterfeiting tracking function

Abstract

This invention discloses an automated end-to-end management system for invoices with anti-counterfeiting tracking capabilities, including a traceability anchor point generation module, an anti-counterfeiting verification and classification module, a watermark injection and circulation module, and a cross-system verification module. This invention generates physical feature fingerprints by fusing hash values ​​and QR code fault-tolerant distribution feature vectors, binding these fingerprints to invoice data to form traceability anchor points; achieves high-precision format verification based on pixel density feature comparison technology using micro-grid arrays; utilizes multi-dimensional semantic tags for intelligent classification and storage; employs invisible circulation node watermark technology to ensure cross-system circulation security; and combines a traceability graph reconstruction mechanism to achieve accurate tampering accountability. This invention effectively improves the reliability of anti-counterfeiting capabilities, achieves end-to-end tracking and real-time deduplication, and provides secure and efficient technical support for enterprise financial and tax management.

Description

Technical Field

[0001] This invention relates to the field of electronic document anti-counterfeiting technology, and more specifically, to an automated management and control system for the entire invoice chain with anti-counterfeiting tracking capabilities. Background Technology

[0002] As enterprises deepen their digital transformation, existing e-invoice management technologies face severe security challenges and efficiency bottlenecks. Current invoice anti-counterfeiting mechanisms are generally simplistic and vulnerable, relying primarily on simple invoice number verification or fixed anti-counterfeiting marks. These methods are ineffective against increasingly sophisticated forgery and tampering techniques, making enterprise financial systems susceptible to fraud attacks. In real-world business scenarios, finance personnel struggle to identify meticulously modified invoices, especially those with minor adjustments to amounts, tax rates, or buyer information. These alterations often easily evade detection by traditional verification methods. With increasingly complex business processes, invoices frequently circulate between multiple platforms, including financial, reimbursement, tax, and auditing systems, yet a comprehensive tracking and verification mechanism is lacking, creating "blind spots" and "breakpoints" in anti-counterfeiting control. This fragmented nature of cross-system circulation allows the same invoice to be repeatedly submitted for reimbursement or accounting without detection, leading to financial losses and risks. When financial irregularities are finally discovered, existing systems often fail to accurately pinpoint the specific stage and responsible party, and the broken chain of responsibility severely hinders risk management and compliance governance. Furthermore, enterprises face the pressure of storing and managing massive amounts of invoice data. Traditional classification methods based on fixed rules lack flexibility and intelligence, making it difficult to adapt to complex and ever-changing business scenarios. Extensive manual intervention is not only inefficient but also increases the possibility of human error. In the verification process with tax authorities, the synchronous operation mode often forces enterprises to interrupt their processing while waiting for verification. During this waiting period, there is a lack of effective security mechanisms, which slows down business efficiency and leaves security risks.

[0003] In view of this, the present invention proposes an automated management and control system for the entire invoice chain with anti-counterfeiting tracking to solve the above problems. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art and to achieve the above objectives, the present invention provides the following technical solution: an automated management and control system for the entire invoice supply chain with anti-counterfeiting tracking capabilities, comprising: The traceability anchor point generation module is used to obtain the invoice source file, extract the invoice data information and the physical feature fingerprint of the invoice source file, bind the physical feature fingerprint with the invoice data information to generate traceability anchor points, and store them in the first traceability database. The anti-counterfeiting verification and classification module is used to perform layout grid alignment verification on the invoice source file based on the traceability anchor point, and after the verification is passed, construct multi-dimensional semantic tags based on the invoice data information, and determine the classification storage node of the invoice source file based on the multi-dimensional semantic tags; The watermark injection and transfer module is used to generate a transfer node watermark corresponding to the target system when a transfer request for an invoice source file is received, inject the transfer node watermark into the metadata of the invoice source file to form watermarked invoice data, and push the watermarked invoice data to the target system. The cross-system verification module is used to extract the physical feature fingerprint carried in the watermarked invoice data after the target system receives it, and compare it with the traceability anchor point in the first traceability database. If they match, the flow status record of the traceability anchor point is updated to complete the full-link control.

[0005] The technical effects and advantages of the present invention, which provides an automated end-to-end management and control system for invoices with anti-counterfeiting tracking: This invention enhances the reliability and security of anti-counterfeiting mechanisms, overcoming the technical bottlenecks of single-feature anti-counterfeiting. High-precision format verification effectively captures minor alterations, improving the accuracy of authenticity verification. The end-to-end tracking system solves the challenge of data consistency verification in cross-system environments, ensuring the integrity of the transfer process. The real-time deduplication mechanism effectively resolves data conflicts in multi-system parallel processing environments, eliminating the risk of reuse. The source tracing and location function enables accurate identification of abnormal nodes, providing technical support for responsibility delineation. The intelligent classification mechanism optimizes the processing efficiency and storage resource utilization of massive amounts of data. The combination of asynchronous verification and dynamic security verification improves processing parallelism while ensuring verification security. Attached Figure Description

[0006] Figure 1 This is an architecture diagram of an automated management and control system for the entire invoice supply chain with anti-counterfeiting tracking, according to the present invention. Detailed Implementation

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

[0008] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0009] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0010] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0011] The following description, in conjunction with the accompanying drawings, details a fully automated invoice management system with anti-counterfeiting tracking provided in this application, through specific embodiments and application scenarios.

[0012] This application provides an automated end-to-end invoice management system with anti-counterfeiting tracking, which can be used in scenarios such as enterprise financial and tax management, tax supervision, and financial auditing. Based on the above application scenarios, it can be understood that the executing entity of each module can be a computer device. This computer device refers to any electronic device with data computing, processing, and storage capabilities, such as servers, PCs (Personal Computers), tablet computers, and other terminal devices. This application does not limit this.

[0013] Figure 1 This is an architecture diagram of an automated management and control system for the entire invoice supply chain with anti-counterfeiting tracking, provided in an embodiment of this application. Figure 1 As shown, it includes: The traceability anchor point generation module is used to obtain the invoice source file, extract the invoice data information and the physical feature fingerprint of the invoice source file, bind the physical feature fingerprint with the invoice data information to generate traceability anchor points, and store them in the first traceability database. The anti-counterfeiting verification and classification module is used to perform layout grid alignment verification on the invoice source file based on the traceability anchor point, and after the verification is passed, construct multi-dimensional semantic tags based on the invoice data information, and determine the classification storage node of the invoice source file based on the multi-dimensional semantic tags; The watermark injection and transfer module is used to generate a transfer node watermark corresponding to the target system when a transfer request for an invoice source file is received, inject the transfer node watermark into the metadata of the invoice source file to form watermarked invoice data, and push the watermarked invoice data to the target system. The cross-system verification module is used to extract the physical feature fingerprint carried in the watermarked invoice data after the target system receives it, and compare it with the traceability anchor point in the first traceability database. If they match, the flow status record of the traceability anchor point is updated to complete the full-link control.

[0014] The invoice source file refers to the original electronic invoice file issued by the tax authorities or by the enterprise itself, which contains data elements such as the invoice's information and QR code. The invoice data information refers to the key information displayed on the invoice, such as the invoice code, invoice number, invoice date, amount, tax rate, buyer information, and seller information. The physical fingerprint refers to a digital digest that uniquely identifies the physical characteristics of the invoice file, generated by extracting and calculating features from the binary data stream and QR code of the invoice source file. The traceability anchor point refers to the data structure generated after binding the physical fingerprint point with the invoice data information, used for subsequent anti-counterfeiting verification and tracking. The primary traceability database refers to a secure database specifically storing traceability anchor point data.

[0015] In one embodiment, after receiving the electronic invoice source file uploaded by the enterprise's financial or tax system, the traceability anchor point generation module first parses the binary format of the file to extract invoice data information such as invoice number, invoice code, invoice date, and amount. Simultaneously, it performs a hash operation on the invoice source file to generate a basic hash value and extracts the fault-tolerant distribution feature vector of the QR code image from the file. These two parts are then fused to form a physical feature fingerprint, which uniquely identifies the physical generation state of the invoice source file. Finally, the extracted invoice data information is bound to the physical feature fingerprint to generate a traceability anchor point, which is assigned a globally unique anchor point identifier. The complete traceability anchor point is then stored in the first traceability database.

[0016] After receiving the traceability anchor point, the anti-counterfeiting verification and classification module performs a layout grid alignment verification on the invoice source file based on the information contained in the anchor point. This involves comparing the invoice source file with the standard layout template at the pixel level to verify whether its layout has been tampered with. Upon successful verification, a multi-dimensional semantic tag containing tax entities, business entities, and accounting entities is constructed based on the invoice data. The optimal classification and storage node for the invoice source file is then determined based on these tags, achieving intelligent classification and storage.

[0017] When the watermark injection and transfer module receives a transfer request for the invoice source file (such as for reimbursement, accounting, or auditing), it generates a transfer node watermark based on the source system identifier, target system identifier, and transfer timestamp. This watermark is injected into the metadata of the invoice source file in an invisible manner, forming watermarked invoice data, and then pushed to the target system to achieve secure transfer and tracking of invoices.

[0018] After the target system receives the watermarked invoice data, the cross-system verification module re-extracts its physical fingerprint and compares it with the original traceability anchor stored in the first traceability database. If they match, it proves that the invoice has not been tampered with during the circulation process, and the system updates the circulation status record of the traceability anchor; if they do not match, a tampering alarm is triggered, realizing full-link control and security monitoring.

[0019] In this embodiment of the application, the physical feature fingerprints of the ticket data information and the invoice source file are extracted, and the physical feature fingerprints are bound to the ticket data information to generate traceability anchor points, including: Parse the invoice source file to obtain file format attributes and binary data stream; Perform a hash operation on the binary data stream to generate a basic hash value, and extract the fault-tolerant distribution feature vector of the QR code image in the invoice source file; The physical feature fingerprint is generated by fusing the basic hash value with the fault-tolerant distribution feature vector. The physical feature fingerprint is used to characterize the unique physical generation state of the invoice source file. Key ticket elements are extracted from the ticket data, and these key elements are combined and encapsulated with physical feature fingerprints to generate traceability anchors. A globally unique anchor identifier is then assigned to each traceability anchor.

[0020] Among these, file format attributes can refer to basic information such as the format type, version, and encoding method of the invoice source file. Binary data stream can refer to the original binary data sequence of the invoice source file. Basic hash value can refer to a fixed-length digest value calculated from the binary data stream using algorithms such as SHA-256 and MD5. Fault-tolerant distribution feature vector can refer to the distribution pattern and characteristics of error correction codes in the QR code image; this feature is unique to each QR code. Key invoice elements can refer to the most important identification information in the invoice, such as the invoice code, invoice number, invoice date, and amount. Anchor identifier can refer to the globally unique identifier (GUID) assigned to each traceability anchor.

[0021] In one embodiment, the traceability anchor generation module first receives invoice source files in PDF, OFD, or image format, identifies their format attributes using a file parsing engine, and extracts the complete binary data stream. Then, it performs a SHA-256 hash algorithm on the data stream to calculate a 64-bit base hash value. Simultaneously, it uses image processing technology to extract a QR code image from the invoice source file, analyzes the Reed-Solomon code fault-tolerant distribution characteristics, and generates a feature vector. The base hash value and the fault-tolerant distribution feature vector are fused using a specific algorithm to form a physical fingerprint. This fingerprint uniquely identifies the physical generation state of the invoice source file; even invoices with the same content but generated at different times or on different devices will have different physical fingerprints. Finally, it extracts key invoice elements such as the invoice code, invoice number, and invoice date from the invoice source file, combines these elements with the physical fingerprint using an encryption algorithm, and generates a traceability anchor. A globally unique UUID is assigned to this anchor as its identifier.

[0022] In this embodiment, the invoice source file is parsed to obtain file format attributes and binary data stream; a hash operation is performed on the binary data stream to generate a basic hash value, and the fault-tolerant distribution feature vector of the QR code image in the invoice source file is extracted; the basic hash value and the fault-tolerant distribution feature vector are fused to generate a physical feature fingerprint; key invoice elements are extracted from the invoice data information, and the key invoice elements are combined and encapsulated with the physical feature fingerprint to generate a traceability anchor point. In the above scheme, by fusing hash values ​​and QR code fault-tolerant features to generate a physical feature fingerprint, the problem that traditional invoice anti-counterfeiting methods relying on only a single feature are easily cracked is innovatively solved, greatly improving the anti-counterfeiting and traceability capabilities of invoice documents.

[0023] In this embodiment of the application, the format grid alignment verification of the invoice source file is performed based on the traceability anchor point, including: Retrieve the standard template corresponding to the invoice code and invoice number in the invoice data information; Both the invoice source file and the standard template are divided into micro-grid arrays with a preset resolution. The first pixel density features of each micro-grid in the invoice source file and the second pixel density features of the corresponding micro-grid in the standard template are extracted respectively. The offset between the first pixel density feature and the second pixel density feature is compared one by one. If the number of micro-grids whose offset exceeds the preset tolerance threshold reaches the abnormal warning number, it is determined that the invoice source file has not passed the layout grid alignment verification and is marked as suspected tampering. If all offsets are within the preset tolerance threshold, the invoice source file is determined to have passed the layout grid alignment check.

[0024] Here, "standard template" refers to a standard format template issued by the tax authorities corresponding to a specific type of invoice. "Microgrid array" refers to a set of small grid units that divide the invoice file according to a preset resolution. "First pixel density feature" refers to the pixel distribution density feature within each microgrid in the invoice source file. "Second pixel density feature" refers to the pixel distribution density feature of the corresponding microgrid in the standard template. "Offset" refers to the difference between the two pixel density features. "Preset tolerance threshold" refers to the maximum offset range allowed by the system. "Anomaly warning number" refers to the minimum number of abnormal microgrids required to trigger a tampering alarm.

[0025] In one embodiment, the anti-counterfeiting verification and classification module first extracts the invoice code and invoice number from the traceability anchor point, and retrieves the corresponding standard layout template from the template library based on these two key pieces of information. Then, both the invoice source file and the standard layout template are divided into a 10×15 micro-grid array at a resolution of 300 DPI, resulting in a total of 150 micro-grids. For each micro-grid, its pixel density features are calculated, including multi-dimensional features such as the ratio of black and white pixels, the proportion of text, and edge density. Next, the pixel density features of each micro-grid in the invoice source file are compared one by one with the corresponding pixel density features in the standard template, and the offset between the two is calculated. If the offset of a micro-grid exceeds a preset tolerance threshold (e.g., 10%), the micro-grid is marked as an abnormal micro-grid. The number of abnormal micro-grids is counted. If the number reaches the abnormal warning threshold (e.g., 5% of the total), the invoice source file is determined to have failed the layout grid alignment verification, and the system will automatically mark it as suspected of tampering and trigger the corresponding warning mechanism. If the offset of all micro-grids is within the tolerance threshold, the invoice source file is determined to have passed the layout grid alignment verification.

[0026] In an embodiment of the present application, a standard format template corresponding to the invoice code and invoice number in the invoice data information is retrieved; the invoice source file and the standard format template are both divided into micro-grid arrays with a preset resolution, and the first pixel density features of each micro-grid in the invoice source file and the second pixel density features of the corresponding micro-grid in the standard format template are respectively extracted; the offset amounts of the first pixel density features and the second pixel density features are compared one by one. In the above solution, through the comparison of the pixel density features of the micro-grid array, fine-formatted verification of the invoice source file is achieved, and invoice files with minor tampering can be effectively identified, solving the problem that it is difficult for traditional verification methods to detect fine tampering.

[0027] In an embodiment of the present application, a multi-dimensional semantic tag is constructed according to the invoice data information, and a classification storage node of the invoice source file is determined based on the multi-dimensional semantic tag, including: Entity extraction is performed on the invoice data information to obtain tax entities, business entities, and accounting entities; A three-dimensional semantic vector is constructed based on the tax entity, business entity, and accounting entity, and the three-dimensional semantic vector is input into a pre-trained classification model to output the classification coordinates of the invoice source file in the multi-dimensional classification space; The spatial distance between the classification coordinates and the node feature center points of each candidate classification storage node is calculated, and the candidate classification storage node with the smallest spatial distance is selected as the classification storage node of the invoice source file, and a mapping relationship is established between the anchor identifier of the traceability anchor point and the classification storage node.

[0028] Among them, the tax entity may refer to tax-related information in the invoice, such as tax rate, tax amount, taxpayer identification number, etc. The business entity may refer to business-related information in the invoice, such as commodity name, quantity, unit price, business type, etc. The accounting entity may refer to financial accounting-related information in the invoice, such as total amount, payment method, accounting subject, etc. The three-dimensional semantic vector may refer to a three-dimensional feature representation composed of tax entities, business entities, and accounting entities. The classification model may refer to a machine learning model that has been trained to predict the optimal classification based on the three-dimensional semantic vector. The classification coordinates may refer to the position representation of the invoice source file in the multi-dimensional classification space. The node feature center point may refer to the position of the feature average value of each candidate classification storage node in the multi-dimensional space. The spatial distance may refer to the Euclidean distance or cosine similarity between the classification coordinates and the node feature center point.

[0029] In one embodiment, after the invoice source file passes the layout grid alignment verification, the anti-counterfeiting verification and classification module performs natural language processing entity extraction technology on its invoice data information to identify and extract three types of key entity information: (1) tax entities, including VAT rate, tax amount, taxpayer identification number, etc.; (2) business entities, including commodity or service name, quantity, unit price, business occurrence date, etc.; (3) accounting entities, including total amount, payment method, possible accounting subjects, etc. Then, these three types of entity information are respectively feature encoded to form fixed-dimensional feature vectors, and these vectors are combined to construct a three-dimensional semantic vector. The three-dimensional semantic vector is input into a pre-trained classification model (such as SVM, random forest or deep neural network), and the model will output the precise coordinates of the invoice source file in the multi-dimensional classification space. The system calculates the Euclidean distance between the coordinates and the feature center points of each candidate classification storage node, and selects the node with the smallest distance as the final classification storage location of the invoice source file. At the same time, the system will establish a mapping relationship between the anchor point identifier of the traceability anchor point and the selected classification storage node, which facilitates subsequent rapid location and query.

[0030] In this embodiment, entity extraction is performed on the invoice data to obtain tax entities, business entities, and accounting entities. A three-dimensional semantic vector is constructed based on these entities. This three-dimensional semantic vector is then input into a pre-trained classification model, which outputs the classification coordinates of the invoice source file in a multi-dimensional classification space. The spatial distance between the classification coordinates and the feature center points of each candidate classification storage node is calculated, and the candidate classification storage node with the smallest spatial distance is selected as the classification storage node for the invoice source file. This scheme, through the combination of three-dimensional semantic vectors and a classification model, achieves intelligent and accurate classification of invoice files, solving the problem that traditional fixed-rule classification methods are difficult to adapt to complex business scenarios, and improving the efficiency of invoice storage and retrieval.

[0031] In this embodiment of the application, after performing layout grid alignment verification on the invoice source file based on the traceability anchor point, and before constructing multidimensional semantic tags based on the invoice data information, the method further includes: When the invoice source file passes the layout grid alignment check, the invoice number is extracted from the invoice data information and used as the primary key for deduplication. Broadcast a pre-reservation message containing the deduplication primary key to the cross-system consensus bus, which connects multiple business subsystems; Listen to the conflict detection results fed back by the cross-system consensus bus after receiving the pre-occupancy message. If the conflict detection result indicates that the duplicate primary key has been occupied in any business subsystem, then intercept the subsequent processing flow of the invoice source file and output a duplicate warning. If the conflict detection result indicates no conflict, the primary key for duplicate checking is marked as reserved, and a reservation validity period is set. During the reservation validity period, other invoice documents containing the same primary key for duplicate checking are prevented from entering the processing flow.

[0032] In this context, the deduplication primary key refers to a key field used to uniquely identify an invoice, typically the invoice number. The cross-system consensus bus refers to a communication middleware connecting multiple business subsystems, used to transmit deduplication information and reach consensus. The pre-reservation message refers to a broadcast message containing the deduplication primary key, used to announce the intention to process a specific invoice number. The conflict detection result refers to the detection result returned by the consensus bus regarding whether a conflict exists with the deduplication primary key. The pre-reservation validity period refers to the maximum duration for which the deduplication primary key is marked as pre-reserved.

[0033] In one embodiment, after the invoice source file passes the layout grid alignment verification, the anti-counterfeiting verification and classification module immediately extracts the invoice number (e.g., "12345678901234567890") from the invoice data as the deduplication check key. The system broadcasts a pre-reservation message containing this deduplication check key to the cross-system consensus bus connecting multiple business subsystems (e.g., financial system, reimbursement system, audit system, etc.). Upon receiving the pre-reservation message, the consensus bus immediately checks whether the invoice number already exists in any of the connected business subsystems. If a record with the same invoice number is detected in any business subsystem, the consensus bus returns a "conflict" detection result. Upon receiving the conflict result, the system immediately intercepts the subsequent processing flow of the invoice source file and outputs a "repeated invoice" warning message to the operator or system administrator. If the consensus bus returns a "no conflict" detection result, the system marks the deduplication check key as "pre-reserved" and sets a pre-reservation validity period (e.g., 30 minutes). During this period, any other invoice documents containing the same invoice number will be blocked from entering the processing flow by the system to ensure that no duplicate entries occur before the current processing is completed.

[0034] In this embodiment, when the invoice source file passes the layout grid alignment verification, the invoice number is extracted from the invoice data information as the deduplication primary key; a pre-reservation message containing the deduplication primary key is broadcast to the cross-system consensus bus; the conflict detection result fed back by the cross-system consensus bus after receiving the pre-reservation message is monitored; if the conflict detection result indicates no conflict, the deduplication primary key is marked as pre-reserved, and a pre-reservation validity period is set. In the above scheme, through the cross-system consensus bus and the pre-reservation mechanism, real-time deduplication and conflict prevention of invoices in a multi-system environment are realized, effectively preventing the risks of invoice reuse and reimbursement, and improving the compliance of enterprise financial management.

[0035] In this embodiment of the application, a watermark for a transfer node corresponding to the target system is generated, and the watermark for the transfer node is injected into the metadata of the invoice source file to form watermarked invoice data, including: Obtain the source system identifier that initiates the transfer request and the target system identifier that receives the transfer request, and record the transfer initiation timestamp; Based on the source system identifier, target system identifier, and transfer initiation timestamp, transfer context information is generated, and the transfer context information is encrypted and encoded to generate a transfer node watermark; Parse the metadata structure of the invoice source file, locate the non-displayable extended metadata field, and write the flow node watermark into the non-displayable extended metadata field to ensure that the visual presentation of the invoice source file is not changed; The invoice source file containing the watermark of the transfer node is encapsulated into watermarked invoice data, and the injection log of the watermark of the transfer node is recorded in the first traceability database.

[0036] Specifically, the source system identifier can refer to the unique identifier of the business system that initiated the transfer request. The target system identifier can refer to the unique identifier of the business system that received the transfer request. The transfer initiation timestamp can refer to the precise time record of the start of the transfer operation. The transfer context information can refer to a data structure containing complete transfer environment information such as the source system, target system, and time. The non-displayable extended metadata field can refer to the metadata area in the invoice file that does not affect the visual presentation and can be used to store additional information. The injection log can refer to the detailed information recorded in the watermark injection operation, including the operation time, watermark content, and operation result.

[0037] In one embodiment, when the watermark injection and transfer module receives a transfer request for an invoice source file (e.g., from the financial system to the audit system), it first obtains the source system identifier (e.g., "FIN_SYS_001") and the target system identifier (e.g., "AUDIT_SYS_002"), and records the current transfer initiation timestamp (e.g., "2025-04-30 14:30:22.135"). Next, these three pieces of information are combined into structured transfer context information and encrypted using algorithms such as RSA or AES to generate a digitally signed transfer node watermark. Then, the system parses the metadata structure of the invoice source file (PDF, OFD, etc.) and identifies the non-displayable extended metadata fields, which are typically not rendered and displayed by invoice reading software. The system writes the generated transfer node watermark into these non-displayable fields, ensuring that the visual presentation of the invoice file is not altered. Finally, the watermarked invoice source file is packaged into watermarked invoice data, and detailed watermark injection logs are recorded in the first traceability database, including watermark content, injection time, source system, target system, and other information, for subsequent tracking and auditing.

[0038] In this embodiment, the source system identifier that initiates the transfer request and the target system identifier that receives the transfer request are obtained, and the transfer initiation timestamp is recorded. Transfer context information is generated based on the source system identifier, target system identifier, and transfer initiation timestamp. The transfer context information is then encrypted to generate a transfer node watermark. The metadata structure of the invoice source file is parsed, and the non-displayable extended metadata field is located. The transfer node watermark is then written into the non-displayable extended metadata field. In this solution, by injecting an invisible transfer node watermark into the invoice metadata, the entire invoice transfer process is made traceable without affecting the normal use of the invoice, solving the problem of traditional transfer methods being unable to trace responsibility and verify authenticity.

[0039] In this embodiment of the application, after the target system receives the watermarked invoice data, it extracts the physical feature fingerprint carried therein and compares it with the traceability anchor points in the first traceability database for verification, including: After the target system receives the watermarked invoice data, it re-executes the physical feature fingerprint extraction operation on the watermarked invoice data to generate the current physical feature fingerprint; Parse the metadata of the watermarked invoice data to obtain the anchor point identifier of the traceability anchor point, and read the original physical feature fingerprint from the first traceability database based on the anchor point identifier; The system compares the current physical fingerprint with the original physical fingerprint. If they do not match, it determines that the watermarked invoice data has been tampered with or replaced during the transfer process, refuses to accept it, and generates a tampering tracking alarm. If they match, the watermarked invoice data is confirmed to be complete. The watermarks at the transfer nodes are then extracted and parsed to verify the legality of the transfer path.

[0040] The current physical fingerprint refers to the physical fingerprint re-extracted by the target system after receiving the watermarked invoice data. The original physical fingerprint refers to the initial physical fingerprint stored in the first traceability database and bound to the traceability anchor point. The tampering tracking alarm refers to the alarm information issued by the system when it detects that the data has been tampered with, including detailed information such as the location and content of the tampering.

[0041] In one embodiment, after the target system receives the watermarked invoice data, the cross-system verification module immediately invokes the same algorithm as the traceability anchor generation module to re-execute the physical feature fingerprint extraction operation on the data, generating the current physical feature fingerprint. Simultaneously, the system parses the metadata of the watermarked invoice data to obtain the anchor identifier (such as a UUID) of the traceability anchor, and uses this identifier to query and read the corresponding original physical feature fingerprint from the first traceability database. The system uses a secure hash comparison algorithm to compare the consistency between the current physical feature fingerprint and the original physical feature fingerprint. If they are inconsistent, it indicates that the watermarked invoice data may have been tampered with or replaced during the circulation process. The system will immediately refuse to receive the data and generate a tampering tracking alarm with detailed information, triggering a security response mechanism. If they are consistent, it proves that the watermarked invoice data has maintained its integrity during the circulation process. The system will further extract and parse the watermarks of the circulation nodes to verify whether the invoice's circulation path conforms to expectations and authorization, confirming the legality of its circulation.

[0042] In this embodiment, after the target system receives watermarked invoice data, it re-performs the physical feature fingerprint extraction operation on the watermarked invoice data to generate the current physical feature fingerprint; it parses the metadata of the watermarked invoice data to obtain the anchor point identifier of the traceability anchor point, and reads the original physical feature fingerprint from the first traceability database based on the anchor point identifier; and it compares the consistency between the current physical feature fingerprint and the original physical feature fingerprint. In the above scheme, through real-time comparison and verification of physical feature fingerprints, the integrity verification of invoices during cross-system circulation is achieved, which can accurately identify tampered invoice files and ensure the security and reliability of invoice data.

[0043] In this embodiment of the application, after generating the tampering tracking alert, the method further includes: Based on the tampering tracking alarm triggering the source map reconstruction mechanism, all injection logs and flow status records associated with anchor point identifiers are obtained from the first source database; The injection logs and circulation status records are sorted according to time series to construct a full lifecycle circulation map of watermarked invoice data; In the full life cycle flow map, locate the map node where the current physical feature fingerprint differs from the original physical feature fingerprint, and mark the map node as an abnormal tampering node. Extract the source system identifier and transfer initiation timestamp corresponding to the abnormal tampering node, generate a tampering responsibility traceability report and push it to the control terminal.

[0044] The traceability mapping reconstruction mechanism refers to a technical mechanism that is automatically triggered after tampering is detected to reconstruct the complete circulation path of an invoice. The full lifecycle circulation map refers to a visual graphical representation that records all circulation states and operations of an invoice from its generation to the present moment. An abnormal tampering node refers to a specific node in the circulation map where the physical fingerprint of the invoice changes, typically indicating the location where tampering occurred. The tampering responsibility tracing report refers to a report document automatically generated by the system that records detailed information related to tampering and the responsible party. The control terminal refers to the management and control terminal device or software interface that receives and displays system security alarms.

[0045] In one embodiment, when the system detects an inconsistency in the physical fingerprint of watermarked invoice data and generates a tampering tracking alert, it immediately triggers a source map reconstruction mechanism. This mechanism first queries the first source database for all injection logs and flow status records associated with the anchor identifier of the tampered invoice, including information such as the source system, target system, and timestamp for each flow. Then, the system sorts these records chronologically to construct a complete invoice lifecycle flow map, clearly showing all flow paths and operation history of the invoice from its generation. In this map, the system compares the physical fingerprint information recorded at each node to accurately locate the node where the current physical fingerprint first diverges from the original physical fingerprint, marking this node as an abnormal tampering node. Finally, the system extracts the source system identifier (such as the business system being operated on) and the flow initiation timestamp from the abnormal tampering node, and combines this with operator information (if any) to generate a detailed tampering responsibility tracing report. This report is automatically pushed to the management terminal for subsequent investigation and processing by administrators.

[0046] In this embodiment, a source map reconstruction mechanism triggered by a tampering tracking alarm is used to retrieve all injection logs and flow status records associated with anchor point identifiers from the first source database. The injection logs and flow status records are then sorted according to time sequence to construct a full lifecycle flow map of the watermarked invoice data. Within this full lifecycle flow map, the nodes where the current physical fingerprint differs from the original physical fingerprint are located. This solution, through source map reconstruction and abnormal node location, enables precise accountability for invoice tampering. It not only identifies the specific stage where the tampering occurred but also clarifies the responsible party, providing strong support for enterprise internal control management.

[0047] In this embodiment of the application, the system further includes: After the invoice source file is stored in the first traceability database, an asynchronous verification request is initiated to the external tax verification interface, and an initial credibility weight is assigned to the traceability anchor point. If a verification result is received from an external tax verification interface within the preset first time period, the initial credibility weight will be increased to the highest credibility weight. If the verification result is not received within the first time period, the initial credibility weight will be calculated by decreasing it according to the preset attenuation coefficient over time. When the initial credibility weight decays to the warning weight threshold, a secondary grid alignment verification of the invoice source file is automatically triggered, and the physical feature fingerprint is regenerated and compared with the original physical feature fingerprint in the traceability anchor point to eliminate the risk of tampering during the verification waiting period.

[0048] Among these, the external tax verification interface refers to the official interface connected to the tax department's system used to verify the authenticity of invoices. Asynchronous verification requests refer to invoice authenticity verification requests performed in the background without blocking the main process. Initial credibility weight refers to the initial credibility score assigned to newly entered invoices by the system. The first time period refers to the maximum time range within which the system waits for external verification results. The highest credibility weight refers to the highest credibility score assigned by the system to officially verified invoices. The decay coefficient refers to the factor that decreases the credibility of unverified invoices over time. The warning weight threshold refers to the minimum credibility weight value that triggers a system security warning. Secondary layout grid alignment verification refers to the repeated layout integrity verification process triggered under specific conditions.

[0049] In one embodiment, after the invoice source file is processed and stored in the first traceability database, the system immediately initiates an asynchronous verification request to the external tax verification interface provided by the State Taxation Administration, and simultaneously assigns an initial credibility weight (e.g., 80 points) to the traceability anchor point of the invoice. If a "verification passed" result is received from the external tax verification interface within a preset first time period (e.g., 2 hours), the system immediately increases the credibility weight of the invoice to the highest credibility weight (e.g., 100 points), indicating that the invoice has passed official verification and has the highest credibility. If no verification result is received within the first time period, the system activates a weight decay mechanism, decreasing the initial credibility weight according to a preset decay coefficient (e.g., decreasing by 5 points per hour). When the credibility weight decays to the warning weight threshold (e.g., 60 points), the system automatically triggers a secondary layout grid alignment verification for the invoice source file and regenerates the physical feature fingerprint, comparing it with the original physical feature fingerprint stored in the traceability anchor point to ensure that the invoice file has not been tampered with during the verification waiting period. If the secondary verification passes, the system will continue to wait for the verification result; if an anomaly is detected, a security warning process will be triggered immediately.

[0050] In this embodiment, after the invoice source file is stored in the first traceability database, an asynchronous verification request is initiated to the external tax verification interface, and an initial credibility weight is assigned to the traceability anchor point. If a verification pass result is received from the external tax verification interface within a preset first time period, the initial credibility weight is increased to the highest credibility weight. If a verification pass result is not received within the first time period, the initial credibility weight is decreased over time according to a preset decay coefficient. When the initial credibility weight decays to the warning weight threshold, a secondary format grid alignment verification of the invoice source file is automatically triggered. In the above scheme, the inefficiency and security risks of traditional verification methods are solved through dynamic management of credibility weight and a secondary verification mechanism, ensuring both system processing efficiency and the security of the invoice verification process.

[0051] In this embodiment of the application, the metadata structure of the invoice source file is parsed to locate the non-explicit extended metadata field, including: Traverse the header information of the invoice source file, construct a metadata dictionary, and identify the standard declaration nodes and extended namespace nodes in the metadata dictionary; Filter out the explicit fields associated with the visual rendering engine in the standard declaration node, and extract the set of candidate non-explicit extended metadata fields that have not been parsed and rendered by the invoice reading application from the extended namespace node; Detect the current data occupancy status of each field in the candidate non-explicit extended metadata field set, remove occupied fields that have been written with custom data, and obtain a set of free fields; According to the preset steganography distribution strategy, at least two non-adjacent free fields are selected from the free field set as target non-explicit extended metadata fields, and the path index of the target non-explicit extended metadata fields in the metadata dictionary is recorded so that the watermark fragments of the transfer nodes can be written into the target non-explicit extended metadata fields in the future.

[0052] The file header information refers to the header area of ​​the invoice source file containing basic information and metadata. The metadata trie refers to the tree structure that organizes the metadata of the invoice file hierarchically. Standard declaration nodes refer to nodes that conform to standard specifications and contain basic metadata. Extended namespace nodes refer to custom namespace nodes used to store extended information. Explicit fields refer to metadata fields that directly affect the visual presentation of the invoice. The candidate non-explicit extended metadata field set refers to the set of metadata fields that may be suitable for storing watermarks and do not affect the visual presentation. Occupied fields refer to metadata fields that have already been written to by other data. The free field set refers to the set of writable metadata fields that have not yet been used. The steganography distribution strategy refers to the distributed storage strategy for watermark data to improve the concealment and security of the watermark. The target non-explicit extended metadata field refers to the metadata field ultimately selected for writing the watermark to the circulation node. The path index refers to the complete access path of the target field in the metadata trie.

[0053] In one embodiment, the watermark injection and processing module first traverses the header information of the invoice source file (such as PDF or OFD format), parses its metadata structure, and constructs a hierarchical metadata trie. Within this tree structure, the system can clearly identify standard declaration nodes (such as file attributes, creation information, etc.) and extended namespace nodes (such as custom attributes, extended fields, etc.). Next, the system filters out display fields in the standard declaration nodes that are directly related to visual rendering, as modifying these fields would affect the visual presentation of the invoice. Simultaneously, it extracts fields from the extended namespace nodes that will not be parsed and rendered by conventional invoice reading software, forming a candidate set of non-displayable extended metadata fields. The system further detects the current data occupancy status of these candidate fields, eliminating fields that have already been written with custom data by other applications, ultimately obtaining a set of completely free and usable fields. Based on a preset steganography distribution strategy (such as distributed data storage, random location selection, etc.), the system selects at least two non-adjacent fields from the free field set as target non-displayable extended metadata fields. This distributed storage strategy improves the watermark's concealment and resistance to attacks. Finally, the system records the complete path index of these target fields in the metadata dictionary tree, preparing for the subsequent writing of watermark fragments from the transfer nodes into these fields.

[0054] In this embodiment, the file header information of the invoice source file is traversed to construct a metadata dictionary tree, identifying standard declaration nodes and extended namespace nodes within the metadata dictionary tree. Explicit fields associated with the visual rendering engine in the standard declaration nodes are filtered out, and a set of candidate non-explicit extended metadata fields not parsed and rendered by the invoice reading application is extracted from the extended namespace nodes. The current data occupancy status of each field in the candidate non-explicit extended metadata field set is detected, and occupied fields that have been written with custom data are removed, resulting in a set of free fields. According to a preset steganography distribution strategy, at least two non-adjacent free fields are selected from the free field set as target non-explicit extended metadata fields. In the above scheme, through metadata dictionary tree construction and intelligent field selection, the watermark data is hidden, ensuring both the normal use and display of the invoice and the security and integrity of the watermark information, providing a solid technical foundation for invoice anti-counterfeiting and tracking.

[0055] The invoice end-to-end automated management and control system with anti-counterfeiting tracking provided in this application embodiment constructs a complete invoice anti-counterfeiting tracking end-to-end automated management and control system through innovative technologies such as physical feature fingerprinting, layout grid alignment verification, multi-dimensional semantic tags, and flow node watermarking. This system can effectively identify tampered invoices, prevent reuse, achieve accurate classification and storage, ensure the secure flow of invoices across multiple systems, and provide end-to-end tracking and accountability capabilities, significantly improving the security, compliance, and efficiency of enterprise financial and tax management.

[0056] The embodiments described above are some, but not all, embodiments of the present invention. The detailed description of the embodiments of the present invention is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0057] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0058] It should be noted that all formulas in this manual are calculated by removing dimensions and taking their numerical values. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0059] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

Claims

1. A fully automated invoice management system with anti-counterfeiting tracking, characterized in that, include: The traceability anchor point generation module is used to obtain the invoice source file, extract the invoice data information and the physical feature fingerprint of the invoice source file, bind the physical feature fingerprint with the invoice data information to generate a traceability anchor point, and store it in the first traceability database. The anti-counterfeiting verification and classification module is used to perform layout grid alignment verification on the invoice source file based on the traceability anchor point, and after the verification is passed, construct multi-dimensional semantic tags based on the invoice data information, and determine the classification storage node of the invoice source file based on the multi-dimensional semantic tags; The watermark injection and transfer module is used to generate a transfer node watermark corresponding to the target system when a transfer request for the invoice source file is received, inject the transfer node watermark into the metadata of the invoice source file to form watermarked invoice data, and push the watermarked invoice data to the target system. The cross-system verification module is used to extract the physical feature fingerprint carried in the watermarked invoice data after the target system receives it, and compare it with the traceability anchor point in the first traceability database. If they match, the module updates the flow status record of the traceability anchor point to complete the end-to-end control.

2. The control system according to claim 1, characterized in that, The step of extracting the ticket data information and the physical feature fingerprint of the invoice source file, and binding the physical feature fingerprint with the ticket data information to generate a traceability anchor point, includes: Parse the invoice source file to obtain file format attributes and binary data stream; A hash operation is performed on the binary data stream to generate a basic hash value, and the fault-tolerant distribution feature vector of the QR code image in the invoice source file is extracted; The physical feature fingerprint is generated by fusing the basic hash value with the fault-tolerant distribution feature vector. Key ticket elements are extracted from the ticket data information, and the key ticket elements are combined and encapsulated with the physical feature fingerprint to generate the traceability anchor point. A globally unique anchor point identifier is assigned to the traceability anchor point.

3. The control system according to claim 1, characterized in that, The step of performing layout grid alignment verification on the invoice source file based on the traceability anchor point includes: Retrieve the standard template corresponding to the invoice code and invoice number in the invoice data information; Both the invoice source file and the standard template are divided into micro-grid arrays of a preset resolution. The first pixel density features of each micro-grid in the invoice source file and the second pixel density features of the corresponding micro-grid in the standard template are extracted respectively. The offset between the first pixel density feature and the second pixel density feature is compared one by one. If the number of micro-grids with an offset exceeding the preset tolerance threshold reaches the abnormal warning number, it is determined that the invoice source file has not passed the layout grid alignment verification and is marked as suspected tampering. If all the offsets are within the preset tolerance threshold, then the invoice source file is determined to have passed the layout grid alignment check.

4. The control system according to claim 1, characterized in that, The step of constructing multi-dimensional semantic tags based on the ticket data information and determining the classification and storage nodes of the invoice source file based on the multi-dimensional semantic tags includes: Entity extraction is performed on the invoice data information to obtain tax entity, business entity and accounting entity; Based on the tax entity, business entity and accounting entity, a three-dimensional semantic vector is constructed. The three-dimensional semantic vector is input into a pre-trained classification model, and the classification coordinates of the invoice source file in the multi-dimensional classification space are output. Calculate the spatial distance between the classification coordinates and the node feature center point of each candidate classification storage node, select the candidate classification storage node with the smallest spatial distance as the classification storage node of the invoice source file, and establish a mapping relationship between the anchor point identifier of the traceability anchor point and the classification storage node.

5. The control system according to claim 1, characterized in that, After performing layout grid alignment verification on the invoice source file based on the traceability anchor point, and before constructing multidimensional semantic tags based on the invoice data information, the method further includes: When the invoice source file passes the layout grid alignment verification, the invoice number in the invoice data information is extracted as the deduplication primary key; A pre-reservation message containing the deduplication primary key is broadcast to a cross-system consensus bus, which connects multiple business subsystems; The system monitors the conflict detection result fed back by the cross-system consensus bus after receiving the pre-occupancy message. If the conflict detection result indicates that the deduplication primary key has an occupied record in any business subsystem, the system intercepts the subsequent processing flow of the invoice source file and outputs a duplicate warning. If the conflict detection result indicates no conflict, the deduplication primary key is marked as reserved and a reservation validity period is set. During the reservation validity period, other invoice documents containing the same deduplication primary key are prevented from entering the processing flow.

6. The control system according to claim 1, characterized in that, The process of generating a watermark for a transfer node corresponding to the target system and injecting the watermark into the metadata of the invoice source file to form watermarked invoice data includes: Obtain the source system identifier that initiates the transfer request and the target system identifier that receives the transfer request, and record the transfer initiation timestamp; Based on the source system identifier, target system identifier, and transfer initiation timestamp, transfer context information is generated, and the transfer context information is encrypted to generate the transfer node watermark; Parse the metadata structure of the invoice source file, locate the non-display extended metadata field, and write the watermark of the transfer node into the non-display extended metadata field; The invoice source file containing the watermark of the circulation node is encapsulated into the watermarked invoice data, and the injection log of the watermark of the circulation node is recorded in the first traceability database.

7. The control system according to claim 1, characterized in that, The step of extracting the physical feature fingerprint carried in the watermarked invoice data after the target system receives it and comparing it with the traceability anchor points in the first traceability database includes: After the target system receives the watermarked invoice data, it re-executes the physical feature fingerprint extraction operation on the watermarked invoice data to generate the current physical feature fingerprint; Parse the metadata of the watermarked invoice data to obtain the anchor point identifier of the traceability anchor point, and read the original physical feature fingerprint from the first traceability database based on the anchor point identifier; The consistency between the current physical feature fingerprint and the original physical feature fingerprint is compared. If they are inconsistent, it is determined that the watermarked invoice data has been tampered with or replaced during the circulation process. The data is then rejected and a tampering tracking alarm is generated. If they match, the watermarked invoice data is confirmed to be complete, and the watermark of the transfer node is extracted and parsed to verify the legality of the transfer path.

8. The control system according to claim 7, characterized in that, Following the generation of the tampering tracking alert, the following is also included: Based on the tampering tracking alarm triggering the source map reconstruction mechanism, all injection logs and flow status records associated with the anchor point identifier are obtained from the first source database; The injection logs and circulation status records are sorted according to time sequence to construct a full lifecycle circulation map of the watermarked invoice data; In the full life cycle flow map, locate the map node where the current physical feature fingerprint and the original physical feature fingerprint diverge, and mark the map node as an abnormal tampering node; Extract the source system identifier and flow initiation timestamp corresponding to the abnormal tampering node, generate a tampering responsibility tracing report and push it to the management terminal.

9. The control system according to claim 1, characterized in that, Also includes: After the invoice source file is stored in the first traceability database, an asynchronous verification request is initiated to the external tax verification interface, and an initial credibility weight is assigned to the traceability anchor point. If a verification result is received from the external tax verification interface within a preset first time period, the initial credibility weight is increased to the highest credibility weight. If the verification pass result is not received within the first time period, the initial confidence weight is calculated to decrease over time according to a preset attenuation coefficient. When the initial credibility weight decays to the warning weight threshold, a secondary layout grid alignment verification is automatically triggered for the invoice source file, and a new physical feature fingerprint is generated and compared with the original physical feature fingerprint in the traceability anchor point.

10. The control system according to claim 6, characterized in that, The step of parsing the metadata structure of the invoice source file and locating the non-explicit extended metadata fields includes: Traverse the file header information of the invoice source file, construct a metadata dictionary tree, and identify the standard declaration node and extended namespace node in the metadata dictionary tree; Filter out the explicit fields associated with the visual rendering engine in the standard declaration node, and extract the set of candidate non-explicit extended metadata fields that have not been parsed and rendered by the invoice reading application from the extended namespace node; The current data occupancy status of each field in the candidate non-explicit extended metadata field set is detected, and occupied fields that have been written with custom data are removed to obtain a set of free fields; According to the preset steganography distribution strategy, at least two non-adjacent free fields are selected from the set of free fields as target non-display extended metadata fields, and the path index of the target non-display extended metadata fields in the metadata dictionary is recorded so that the watermark fragments of the transfer node can be written into the target non-display extended metadata fields in the future.

Images