Finance and tax management method and system based on block chain

Abstract

The invention provides a financial and tax management method and system based on a block chain, relates to the technical field of block chains, and solves the technical problem of low financial and tax data management efficiency in the prior art. The method comprises the following steps: constructing a three-dimensional fragment chain based on a block chain technology; drawing a transaction network according to the three-dimensional fragment chain; calculating the centrality of each node in the transaction network, and outputting a risk conduction node set; comparing data of each fragment chain in the three-dimensional fragment chain based on the risk conduction node set, and positioning a risk point; the risk points comprise false invoice making, cost false increase and yin-yang contracts; and carrying out risk early warning according to the three-dimensional coordinates of the risk points. The method is used for enterprise finance and tax data management and risk identification and prevention and control processes.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of blockchains, and specifically relates to a blockchain-based financial and tax management method and system. BACKGROUND

[0002] With the complication of market economy and the deep integration of industrial chains, enterprises face the dual challenges of data scale explosion and risk diversification in financial and tax management. The existing technology is difficult to achieve fine management due to the scattered content and low correlation in financial and tax data management. In the existing technology, the financial and tax related data of enterprises are scattered in independent systems or a single blockchain, and are not structured and classified according to business dimensions, which leads to difficulties in cross-verification of data, and the inability to quickly trace the full-link relationship between "industry benchmark - level transaction - business execution". This not only reduces the data management efficiency, but also lays hidden dangers for subsequent risk identification. SUMMARY

[0003] The application provides a blockchain-based financial and tax management method and system, which solves the technical problem of low data management efficiency in the prior art.

[0004] To achieve the above-mentioned purpose, the application adopts the following technical solutions:

[0005] In a first aspect, a blockchain-based financial and tax management method is provided, comprising:

[0006] A three-dimensional sharded chain is constructed based on blockchain technology; the three-dimensional sharded chain includes an industry sharded chain, a level sharded chain and a business sharded chain;

[0007] A transaction network is drawn according to the three-dimensional sharded chain;

[0008] The centrality of each node in the transaction network is calculated, and a risk transmission node set is output;

[0009] Each sharded chain data in the three-dimensional sharded chain is compared based on the risk transmission node set, and a risk point is located; the risk point includes false invoicing, cost virtual increase and yin-yang contract;

[0010] Risk warning is performed according to the three-dimensional coordinates of the risk point.

[0011] Based on the above technical scheme, in the blockchain-based financial tax management method provided in the application, the three-dimensional sharding chain including industry, level and business dimensions is constructed, so that the accurate classification and efficient management of financial tax related data can be realized; the transaction network is drawn according to the three-dimensional sharding chain, so that the transaction association between enterprises can be clearly presented; the centrality of each node in the transaction network is calculated and the risk transmission node set is output, so that the key node with high risk transmission possibility can be quickly determined, and the risk investigation is more targeted. Comparing each sharding chain data based on the risk transmission node set to locate the risk point can effectively identify common financial tax risks such as false invoicing, cost virtual increase and yin-yang contract, and improve the accuracy of risk identification. Finally, the risk warning is carried out according to the three-dimensional coordinates of the risk point, so that the specific dimension and position of the risk can be determined, and timely countermeasures can be taken, so as to comprehensively improve the safety and effectiveness of financial tax management.

[0012] Further, the industry sharding chain includes each sub-chain obtained by dividing each upstream and downstream associated enterprise based on international standard industry classification, and each sub-chain contains an industry type code; the industry sharding chain is used to store industry benchmark data, and the industry accurate data includes material unit price interval, industry average profit margin, compliance transaction period and product upstream and downstream correlation;

[0013] The level sharding chain includes a supplier sub-chain, a core enterprise sub-chain and a distributor sub-chain, and each sub-chain contains a level type code, the level sharding chain is used to record the level attribute and historical transaction record of the transaction subject, and supports the rationality verification of inter-level transactions;

[0014] The business sharding chain includes an invoice processing sub-chain, a fund settlement sub-chain, a tax compliance sub-chain and a contract sub-chain, and each sub-chain contains a business type code, the business sharding chain is used for closed loop verification of tax business flow, and ensures that invoice metadata, payment records, declaration data and contract basic information are cross-verified in the distributed ledger.

[0015] Further, the transaction network is drawn according to the three-dimensional sharding chain, including:

[0016] The interaction records of all smart contracts are extracted from the three-dimensional sharding chain, and the interaction records include transaction timestamp, transaction node ID of both parties, transaction type, transaction amount and currency type;

[0017] The timestamp is converted into a unified time zone time, and the interaction records are sorted in time sequence to build a transaction sequence;

[0018] The transaction sequence is converted into a directed graph to obtain a transaction network; wherein, the nodes of the transaction network represent enterprises, and the node coordinates include industry classification code and hierarchical type code, the edges of the transaction network represent transaction events, the direction is from the payer to the payee, and the weight is the proportion of the transaction amount.

[0019] Furthermore, when drawing the transaction network, the topology is updated by synchronizing the newly added value flow trajectory and payment records on the chain at fixed intervals, and the transaction network is stored in a graph database to achieve real-time query and visualization.

[0020] Furthermore, the process of obtaining the risk transmission node set includes:

[0021] Calculate the degree centrality DC, proximity centrality CC, and betweenness centrality BC for each node;

[0022] The risk transmission coefficient R for each node is calculated using the weighted summation formula: R = w1 × DC + w2 × CC + w3 × BC; where w1, w2, and w3 represent the weight coefficients of each item.

[0023] Nodes with a risk transmission coefficient greater than a preset threshold are added to the risk transmission node set and output.

[0024] Furthermore, the method for locating the risk points of false invoices includes:

[0025] The invoice metadata in the invoice processing subchain is linked with the payment records in the fund settlement subchain, the input and output reconciliation relationship in the tax compliance subchain, and the material unit price range in the industry segment chain; the invoice metadata includes the payer, the name of the traded item, the quantity of the traded item, and the unit price of the traded item.

[0026] The target node in the invoice processing subchain will be marked as a risk point of fraudulent invoicing if at least one of the following conditions is met:

[0027] (1) The actual payer in the payment record is inconsistent with the payer in the invoice metadata;

[0028] (2) The transaction product name in the invoice metadata and the product category of the input invoice in the input-output reconciliation relationship have no production relevance; the production relevance is determined by word vector model and cosine similarity.

[0029] (3) The transaction unit price in the invoice metadata is not within the material unit price range.

[0030] Furthermore, when the upstream and downstream related enterprises of an enterprise include multinational corporations, the risk point also includes transfer pricing, and the method for locating the risk point of transfer pricing includes:

[0031] Based on the taxpayer information in the tax compliance sub-chain, enterprises in low-tax areas and enterprises in high-tax areas are marked in the hierarchical sharded chain;

[0032] Based on the operating profit and operating cost data in the hierarchical sharding chain, calculate the profit margin R of enterprises in low-tax areas. low Profit margin R of companies in high-tax zones high ;

[0033] Enterprises are categorized based on their industry type codes in high-tax and low-tax zones, and the median profit margin R of enterprises with the same industry type code is retrieved from the industry sharding chain. med ;

[0034] When the profit margin R of enterprises in low-tax zones low >α1×R med or the profit margin R of companies in high-tax zones high <α2×R med At that time, the target node in the hierarchical sharding chain is marked as a transfer pricing risk point; where α1 and α2 represent preset proportional coefficients;

[0035] When the service fee in the tax compliance subchain exceeds a preset percentage of the company's consolidated revenue, the target node in the tax compliance subchain will be marked as a transfer pricing risk point.

[0036] Furthermore, the method for locating the risk points of the alleged cost inflation includes:

[0037] Extract the unit price range and industry standard deviation of materials from the industry segmentation chain;

[0038] Extract invoice metadata from the invoice processing subchain, including the transaction name, transaction quantity, and transaction unit price;

[0039] The industry benchmark price is obtained based on the unit price range of the material; the industry benchmark price is the average of the maximum and minimum values ​​in the unit price range of the material.

[0040] Extract the agreed purchase quantity from the contract subchain, and calculate the ratio of the transaction quantity to the agreed purchase quantity to obtain the capacity utilization rate;

[0041] The cost deviation index is calculated using the following formula: Cost Deviation Index = |Transaction Price - (Industry Benchmark Price × Capacity Utilization Rate)| / Industry Standard Deviation;

[0042] When the cost deviation index exceeds the preset cost deviation threshold, the target node in the invoice subchain is marked as a risk point of inflated costs.

[0043] Furthermore, the method for locating the risk points of the aforementioned dual contracts includes:

[0044] Extract contract data and invoice data from the business segment chain. The contract data includes the contract amount M. c Signing time T c The invoice data includes the actual amount M. i Issuance time T i ;

[0045] Calculate the difference rate between the contract amount and the actual amount: Difference rate = |M c -M i | / M c ;

[0046] Extract multiple payment records under the same contract from the fund settlement subchain and calculate the total payment amount M. total ;

[0047] A target node in the business sharding chain will be marked as a risk point for dual contracts if at least one of the following conditions is met:

[0048] (1) The difference rate is greater than the preset ratio;

[0049] (2) Total payment amount M total ≠ Contract Amount M c ;

[0050] (3) Signing time T c With the time of issuance T i The time difference is greater than the preset time difference.

[0051] Secondly, this application provides a blockchain-based financial and tax management system, including: a blockchain construction module, a transaction network drawing module, a centrality calculation module, a risk point location module, and a risk early warning module; wherein,

[0052] The blockchain construction module is used to construct a three-dimensional sharded chain based on blockchain technology, which includes industry sharded chains, hierarchical sharded chains, and business sharded chains.

[0053] The transaction network drawing module is used to draw the transaction network based on the three-dimensional sharded chain;

[0054] The centrality calculation module is used to calculate the centrality of each node in the transaction network and output the risk transmission node set;

[0055] The risk point location module is used to compare the data of each shard chain in the three-dimensional shard chain based on the risk transmission node set, and locate risk points including false invoices, inflated costs and dual contracts;

[0056] The risk warning module is used to provide risk warnings based on the three-dimensional coordinates of the risk points.

[0057] Thirdly, this application provides a blockchain-based financial and tax management device, comprising: a communication unit and a processing unit; wherein,

[0058] The communication unit is used to acquire data from each shard in the three-dimensional shard chain and transaction information of the enterprise's upstream and downstream businesses;

[0059] The processing unit is used to construct a three-dimensional sharded chain based on blockchain technology, draw a transaction network based on the three-dimensional sharded chain, calculate the centrality of each node in the transaction network and output a risk transmission node set, locate risk points based on the risk transmission node set, and provide risk warnings based on the three-dimensional coordinates of the risk points.

[0060] Fourthly, a blockchain-based tax management device is provided, comprising: a processor and a storage medium; the storage medium includes instructions, and the processor is used to execute the instructions to implement the methods described in the first aspect and any possible implementation thereof. This blockchain-based tax management device can be an electronic device or a chip within an electronic device.

[0061] Fifthly, this application provides a computer-readable storage medium storing instructions that, when executed on a blockchain-based tax management device, cause the blockchain-based tax management device to perform the methods described in the first aspect and any possible implementation thereof.

[0062] Sixthly, this application provides a computer program product containing instructions that, when run on a blockchain-based financial and tax management device, cause the blockchain-based financial and tax management device to perform the methods described in the first aspect and any possible implementation thereof.

[0063] This application provides a blockchain-based financial and tax management method and system. Through the refined design of a three-dimensional sharded chain, it enhances the targeting and efficiency of financial and tax data management. Furthermore, the data from each shard can be managed independently yet cross-verified, laying the foundation for accurate risk identification. Simultaneously, by synchronizing transaction data and updating the topology at fixed intervals, combined with a graph database, it enables real-time querying and visualization, making the transaction network clearly traceable and facilitating the rapid capture of potential risks.

[0064] In addition, multi-dimensional comparison and calculation rules were designed to address risks such as false invoicing, inflated costs, dual contracts, and transfer pricing in cross-border transactions. After filtering out the risk transmission node set through node centrality, early warnings are generated by combining three-dimensional coordinates, making risk warnings more targeted and timely, and effectively preventing various financial and tax risks.

[0065] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

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

[0067] Figure 1 A diagram illustrating a blockchain-based financial and tax management system architecture is provided for embodiments of this application.

[0068] Figure 2 A flowchart illustrating a blockchain-based financial and tax management method provided for an embodiment of this application;

[0069] Figure 3 A flowchart illustrating another blockchain-based financial and tax management method provided in this application embodiment;

[0070] Figure 4 A flowchart illustrating another blockchain-based financial and tax management method provided in this application embodiment;

[0071] Figure 5 A schematic diagram of the structure of a blockchain-based financial and tax management device provided in this application embodiment;

[0072] Figure 6 This is a schematic diagram of the hardware structure of a blockchain-based financial and tax management device provided in an embodiment of this application. Detailed Implementation

[0073] In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. The terms "first," "second," etc., do not limit the quantity or order of execution, and "first," "second," etc., do not necessarily imply differences.

[0074] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0075] The blockchain-based financial and tax management method provided in this application embodiment can be applied to, for example... Figure 1 In the blockchain-based financial and tax management system shown, such as Figure 1 As shown, the communication system includes: a blockchain construction module, a transaction network drawing module, a centrality calculation module, a risk point location module, and a risk early warning module; among which,

[0076] The blockchain building module is used to construct a three-dimensional sharded chain based on blockchain technology, which includes industry sharded chains, hierarchical sharded chains, and business sharded chains.

[0077] The transaction network drawing module is used to draw the transaction network based on the 3D sharded chain;

[0078] The centrality calculation module is used to calculate the centrality of each node in the transaction network and output the risk transmission node set;

[0079] The risk point location module is used to compare the data of each shard chain in the three-dimensional shard chain based on the risk transmission node set, and locate risk points including false invoices, inflated costs and dual contracts;

[0080] The risk warning module is used to provide risk warnings based on the three-dimensional coordinates of risk points.

[0081] To address the technical problems of fragmented financial and tax management data and inaccurate risk identification in existing technologies, this application provides a blockchain-based financial and tax management method and system. The method includes: constructing a three-dimensional sharded chain based on blockchain technology; the three-dimensional sharded chain includes an industry sharded chain, a hierarchical sharded chain, and a business sharded chain.

[0082] Draw the transaction network based on the 3D sharded chain;

[0083] Calculate the centrality of each node in the transaction network and output the risk transmission node set;

[0084] Based on the risk transmission node set, the data of each shard chain in the three-dimensional shard chain are compared to locate risk points; the risk points include false invoices, inflated costs, and dual contracts;

[0085] Risk warnings are issued based on the three-dimensional coordinates of risk points.

[0086] Based on this, this application realizes the structured management and cross-validation of financial and tax data through a three-dimensional sharded chain. By leveraging the transaction network and node centrality, it accurately locates risk transmission nodes, thereby efficiently identifying various risk points and providing timely warnings, thus improving the accuracy of financial and tax management and risk prevention and control capabilities.

[0087] like Figure 2 As shown in the embodiment of this application, a blockchain-based financial and tax management method includes:

[0088] S1. Construct a three-dimensional sharded chain based on blockchain technology.

[0089] The three-dimensional sharding chain includes industry sharding chain, hierarchical sharding chain, and business sharding chain, which are used to store financial and tax-related data in different dimensions: industry sharding chain is used to store basic information about the industry to which the enterprise belongs and benchmark transaction data within the industry; hierarchical sharding chain is used to store the hierarchical attributes of the enterprise in the industrial chain and transaction relationship data between hierarchical levels; business sharding chain is used to store the processing data of various financial and tax business of the enterprise.

[0090] In some implementations, the construction process may include: First, clarifying the rules for dividing the three-dimensional shards. The industry dimension is determined based on international standard industry classifications or national economic industry classifications. The hierarchical dimension is divided according to supply chain roles, such as suppliers, core enterprises, and distributors. The business dimension covers key financial and tax business types such as invoice processing, fund settlement, and contract management. Next, the nodes joining the blockchain network are classified. Each node needs to submit information such as its industry attributes, hierarchical positioning, and business scope. The system assigns corresponding three-dimensional coordinates to the nodes according to preset rules, determining their affiliation in each shard chain.

[0091] Subsequently, based on blockchain sharding technology, all network nodes (including enterprise nodes, regulatory nodes, and other computing devices participating in network operation) are divided into different sub-networks according to the above classification. Each sub-network maintains its corresponding shard chain—the industry sub-network maintains the industry shard chain, the hierarchical sub-network maintains the hierarchical shard chain, and the business sub-network maintains the business shard chain. Nodes within a sub-network jointly participate in transaction verification and block generation for their respective shard chains. Simultaneously, a cross-shard communication protocol is deployed to ensure data interaction and sharing between shard chains. Furthermore, the cross-shard communication protocol employs an atomic cross-chain transaction mechanism, achieving atomic updates of cross-shard data through two-phase commit (2PC) or hash time-locked contracts (HTLC). When data on a shard chain needs to be updated, it must be verified through cross-shard consensus nodes to ensure that data on all related shard chains is modified synchronously, avoiding intermediate states of partial success and partial failure.

[0092] Furthermore, to ensure the consistency and security of data across all shards, each sub-network employs a consensus mechanism (such as Practical Byzantine Fault Tolerance, PBFT) to generate blocks and maintain a distributed ledger through consensus verification among nodes. The system also includes a dynamic adjustment mechanism, triggered by conditions such as: ① the number of nodes in a sub-network exceeding 30% of the total number of nodes in the network; ② the average transaction processing latency of the sub-network exceeding 5 seconds. The optimization algorithm employs a greedy algorithm to migrate some nodes from high-load sub-networks to low-load sub-networks. The migration process verifies node identity through signatures, ensuring that the hash value remains unchanged after data migration. This ensures that the three-dimensional sharded chains can independently and efficiently process data across various dimensions, while also forming a complete financial and tax management data system through collaborative operation.

[0093] It should be noted that the 3D sharded chain is a blockchain network consisting of three interconnected yet relatively independent sub-chains. Each sharded chain can independently process data in its corresponding dimension, and can also achieve cross-data access and verification through preset interfaces.

[0094] For example, industry-specific chains can be divided into major categories such as agriculture, manufacturing, and services; hierarchical chains can be divided into upstream suppliers, midstream core enterprises, and downstream distributors; and business-specific chains can be divided into business types such as invoice management and fund settlement. The three are linked through a unique enterprise identifier (such as a unified social credit code).

[0095] S2. Draw the transaction network based on the three-dimensional sharded chain.

[0096] The transaction network is used to visually display the transaction relationships and flow between enterprises and their upstream and downstream related enterprises, providing a basis for identifying the risk transmission path in transactions.

[0097] In some implementations, a transaction network can be drawn based on the transaction records stored in the 3D sharded chain. The specific steps are as follows: extract the transaction information between enterprises from each sharded chain, including the identifiers of the transacting parties, the transaction amount, the transaction time, etc.; construct a directed graph with enterprises as nodes and transaction relationships as edges, where the direction of the edges represents the flow of transaction funds, and the weight of the edges can be set based on the transaction amount; and mark the nodes according to their attributes (industry, level, business) in the 3D sharded chain.

[0098] It should be noted that the transaction network is a digital mapping of the actual transaction relationships between enterprises. The attributes of its nodes and edges all come from real data of the three-dimensional sharded chain, ensuring the authenticity and traceability of the network.

[0099] For example, the industry attributes of company A (manufacturing) and company B (raw material supply) are extracted from the industry segment chain, the hierarchical relationship of A as the core company and B as the first-level supplier is extracted from the hierarchical segment chain, and the transaction amount and time of the two are extracted from the business segment chain. Then, the transaction edge from A to B is drawn to form a local transaction network.

[0100] S3. Calculate the centrality of each node in the transaction network and output the risk transmission node set.

[0101] Centrality includes degree centrality (DC, the number of connections a node has to other nodes), closeness centrality (CC, the reciprocal of the average distance from a node to all other nodes), and betweenness centrality (BC, the number of times a node is on the shortest path to other nodes).

[0102] In some implementations, the risk transmission node set is used to represent the set of enterprise nodes with a high probability of risk transmission in the transaction network. It can be determined by the following methods: calculating the DC, CC, and BC of each node respectively; assigning weights to each centrality and calculating the risk transmission coefficient of the node through a weighted summation formula; and including nodes with risk transmission coefficients greater than a preset threshold into the risk transmission node set and outputting them.

[0103] It should be noted that centrality calculation is based on the topology of the transaction network and transaction data. The screening threshold for the risk transmission node set can be adjusted according to industry characteristics or regulatory requirements to adapt to the risk identification needs of different scenarios. For example, the initial threshold can be obtained by training a machine learning model, with input parameters including the risk transmission coefficients of nodes involved in risk events within the industry over the past three years and the 95% confidence interval of the model's output threshold. For example, the initial threshold for manufacturing is set to 0.6, and for retail it is set to 0.55. The model is retrained and the threshold is updated annually based on newly added risk event data.

[0104] For example, a core enterprise has direct transactions with 10 suppliers and 5 distributors (high DC), and is located on the shortest transaction path of multiple upstream and downstream enterprises (high BC). After calculation, its risk transmission coefficient exceeds the threshold and it is included in the risk transmission node set.

[0105] S4. Based on the risk transmission node set, compare the data of each shard chain in the three-dimensional shard chain, locate risk points and issue risk warnings.

[0106] Among the risk points are false invoicing, inflated costs, and dual contracts. If the company's upstream and downstream related companies include multinational corporations, the risk points also include transfer pricing, which is used to identify possible violations or abnormal behaviors in the company's financial and tax management.

[0107] In some implementations, false invoices are usually related to invoice data and fund settlement data in the business segment chain; inflated costs indicate that enterprises use false means to raise costs in order to reduce taxes, which is usually related to material price data in the industry segment chain and transaction amount data in the invoice processing sub-chain of the business segment chain; dual contracts are usually related to contract data in the contract sub-chain of the business segment chain and invoice amount data in the invoice processing sub-chain.

[0108] It should be noted that the location of risk points needs to be combined with the characteristics of the risk transmission node set. Priority should be given to comparing cross-shard chain data of high-risk transmission nodes to improve the efficiency of risk identification. Risk warnings are based on the severity of risk points to ensure that the warnings are targeted.

[0109] For example, for a company with a concentration of risk transmission nodes, by comparing the invoice data and fund settlement data in its business segment chain, it was found that the invoice payer and the actual payer were inconsistent, which was identified as a risk point of issuing false invoices and triggered a level one risk warning.

[0110] Based on the above technical solutions, the blockchain-based financial and tax management method provided in this application realizes multi-dimensional management of financial and tax data by constructing a three-dimensional sharded chain. It accurately identifies risk transmission nodes by leveraging the transaction network and node centrality, and locates risk points by comparing data across sharded chains, thus forming a complete financial and tax risk prevention and control system, which can effectively improve the comprehensiveness and accuracy of financial and tax management.

[0111] In one possible implementation of this application embodiment, the above-mentioned S1 can be specifically implemented by the following S101, S102 and S103, which are described in detail below:

[0112] S101. Construct industry-specific sharding chains.

[0113] Among them, the industry segment chain is formed by dividing all upstream and downstream related enterprises according to the International Standard Industrial Classification (ISIC). It is mainly used to store standard information of each industry, such as material unit price range, industry average profit margin, etc., to provide industry benchmark data for subsequent risk point identification.

[0114] In some implementations, the international standard industry classification can adopt ISIC Rev.4 or other authoritative classification systems. During the classification process, each enterprise needs to be assigned a unique industry classification code, and enterprises with the same code are then grouped into the same sub-chain. In addition to storing industry standard information, the sub-chain can also record the enterprise's industry qualifications, industry-related data in historical transactions, etc.

[0115] It should be noted that the sub-chain division of the industry sharding chain needs to maintain stability. When the industry attributes of an enterprise change, the migration needs to be completed through on-chain smart contracts, and the ownership of its associated transaction data needs to be updated synchronously.

[0116] For example, the manufacturing industry can be divided into sub-sectors such as food manufacturing, textile manufacturing, and machinery manufacturing according to ISIC Rev.4. Each sub-sector forms a sub-chain. The machinery manufacturing sub-chain stores data such as the industry unit price range of various mechanical parts and the standards for the reconciliation of purchase and sales of machinery manufacturing enterprises.

[0117] S102, Construct a hierarchical sharding chain.

[0118] The hierarchical sharding chain includes supplier sub-chains, core enterprise sub-chains, and distributor sub-chains. It is mainly used to record actual transaction information between enterprises at different levels and to clarify the position of enterprises in the industrial chain and the flow of transactions.

[0119] In some implementations, the supplier subchain can be further subdivided into first-level supplier subchains, second-level supplier subchains, etc., the core enterprise subchain can be divided according to enterprise size or industry influence, and the distributor subchain can be divided according to region or distribution scope; the transaction information stored in each subchain includes, but is not limited to, the hierarchical attributes of the transacting parties, transaction amount, transaction time, transaction type, etc.

[0120] It should be noted that the hierarchical division of the tiered blockchain should be based on the actual role of the enterprise in the industry chain, rather than the size of the enterprise itself, to ensure that the hierarchical relationship is consistent with the actual transaction scenario and to provide accurate hierarchical coordinates for mapping the upstream and downstream transaction network.

[0121] For example, in the automotive industry chain, auto parts manufacturers belong to the supplier sub-chain (Tier 1 suppliers), vehicle manufacturers belong to the core enterprise sub-chain, and 4S stores belong to the distributor sub-chain. The hierarchical shard chains record the transaction data between parts manufacturers and vehicle manufacturers, and between vehicle manufacturers and 4S stores, respectively.

[0122] S103. Construct a business sharding chain.

[0123] The business shard chain includes an invoice processing subchain, a fund settlement subchain, a tax compliance subchain, and a contract subchain. It is mainly used to realize closed-loop verification of tax business flow and ensure that invoice metadata, payment records, declaration data, and basic contract information can be cross-verified in the distributed ledger.

[0124] In some implementations, the invoice processing subchain stores data on the entire lifecycle of invoices, including issuance, circulation, and authentication; the fund settlement subchain records information such as payment amount, payment time, and payment method for each transaction; the tax compliance subchain stores the company's tax declaration data, tax incentive qualifications, and input / output reconciliation relationships; the contract subchain stores contract signing information, terms and conditions, and change records; and each subchain achieves automatic data synchronization and verification through smart contracts.

[0125] It should be noted that each subchain of the business shard chain must maintain the correlation of data. For example, the invoice and fund settlement data corresponding to a contract must be associated with a unique identifier to ensure the traceability of business processes.

[0126] For example, after a company signs a purchase contract, the contract subchain stores information such as the contract amount and purchase quantity, the invoice processing subchain generates the corresponding invoice metadata (transaction name, quantity, unit price), the fund settlement subchain records the payment amount and time, and the tax compliance subchain verifies the tax compliance of the transaction based on the data from the first three sources, thus achieving cross-verification of the four types of data.

[0127] In some implementations, the storage data of a three-dimensional sharded chain can be as follows:

[0128] (1) Industry Sharding Chain: Based on the International Standard Industry Classification (ISIC), each industry category corresponds to a sub-chain, which is used to store relevant data of enterprises in the industry and to make industry benchmark comparisons.

[0129] Sub-chains are included: Each industry corresponds to one sub-chain (such as a manufacturing sub-chain, a wholesale sub-chain, etc.), and each sub-chain contains the following data items:

[0130] Enterprise registration information: Enterprise ID (Node ID), Enterprise Name, Unified Social Credit Code, Industry Classification Code (ISIC Code);

[0131] Industry financial benchmark data (synchronized from authoritative industry data sources, such as industry associations): industry classification code, benchmark material cost (price range: lowest price, highest price, median price), benchmark labor cost (wage range per unit of labor hour), benchmark energy consumption ratio (energy consumption range per unit of output), benchmark profit margin (reasonable range).

[0132] Enterprise financial data (extracted from compliant financial reports uploaded by the enterprise): report date, material costs, labor costs, energy costs, depreciation costs, capacity utilization rate, and profit margin;

[0133] (2) Hierarchy Sharding Chain: Sub-chains are divided according to the position of an enterprise in the industry chain, including suppliers, core enterprises and distributors, to track value flow and risk transmission.

[0134] It includes subchains: Supplier Subchain, Core Enterprise Subchain, and Distributor Subchain;

[0135] And each subchain contains the following data items (taking the supplier subchain as an example; the core enterprise and distributor are similar):

[0136] Enterprise hierarchical information (extracted from enterprise nodes): Enterprise ID (node ​​ID), enterprise name, hierarchical type code (supplier, core enterprise, distributor), and industry classification code of the industry to which it belongs;

[0137] Cost structure data: block height, material costs (from the benchmark price of the industry sharding chain and the actual purchase price), labor costs (wage data), non-taxable cost items (such as depreciation, amortization expenses, etc.), tax filing amortization standards (such as depreciation rate, amortization ratio, etc.);

[0138] Value flow data (transaction flow summary): Upstream transaction company ID, downstream transaction company ID, transaction amount, and transaction time;

[0139] Profit margin data: Reporting date, operating profit, operating costs, profit margin;

[0140] (3) Business Sharding Chain: Divide the chain into sub-chains according to the business process to realize business closed-loop verification.

[0141] It includes the following subchains: Invoice Processing Subchain, Payment Settlement Subchain, Tax Compliance Subchain, and Contract Subchain; and each subchain contains the following data items:

[0142] 1. Invoice Processing Subchain

[0143] Basic invoice information: invoice code, invoice date, payer company ID, payee company ID, transaction item name, transaction quantity, transaction unit price, and invoice amount;

[0144] Input invoice metadata (when the invoice is used as input): Supplier company ID, purchased item name, purchased quantity, and purchased unit price;

[0145] Sales invoice metadata (when the invoice is a sales invoice): Customer company ID, product name, quantity sold, and unit price;

[0146] 2. Funds Settlement Subchain

[0147] Payment record: Payment transaction number, payer company ID, payee company ID, payment amount, payment time, associated contract number (optional), associated invoice code (optional);

[0148] Payment records (same as above, but from the opposite perspective);

[0149] 3. Tax Compliance Subchain

[0150] Tax declaration data: Declaration company ID, declaration period, output VAT, input VAT, VAT payable, and tax already paid;

[0151] Input and output reconciliation: Invoice code, deduction period, deduction status (deducted / not deducted);

[0152] 3. Contract Subchain

[0153] Basic contract information: Contract number, signing date, contract amount, buyer's company ID, seller's company ID

[0154] Contract performance data: payment records (referencing the payment transaction number from the fund settlement subchain) and invoice records (referencing the invoice code from the invoice processing subchain).

[0155] Based on the above technical solution, by constructing industry-specific sharding chains, hierarchical sharding chains, and business-specific sharding chains, a three-dimensional sharding chain covering industry attributes, industrial chain levels, and specific business processes is formed. This provides a multi-dimensional and cross-verifiable data foundation for subsequent mapping of transaction networks and identification of risk points, ensuring the comprehensiveness and accuracy of data in financial and tax management.

[0156] In one possible implementation of the embodiments of this application, combined with Figure 2 ,like Figure 3 As shown, the above S2 can be implemented through the following S201, S202 and S203, which are explained in detail below:

[0157] S201. Extract and preprocess transaction data.

[0158] This step involves obtaining the basic data required to build the transaction network from the 3D sharded chain and standardizing it to provide a data source with a unified format for subsequent network drawing.

[0159] In some implementations, smart contract interaction records can be extracted from the invoice processing subchain, fund settlement subchain, contract subchain, and hierarchical sharding chain of the business sharding chain. These records include transaction timestamps, the node IDs (enterprise IDs) of both parties to the transaction, transaction type (such as purchase or sales), transaction amount, and currency type. The timestamp conversion can use Coordinated Universal Time (UTC) as the unified time zone. After conversion, the interaction records are sorted according to the order in which the transactions occurred to form an ordered transaction sequence.

[0160] It should be noted that the extracted interaction records must cover the transaction behavior of all related enterprises to ensure the integrity of the transaction network; time sorting helps to clearly present the temporal relationship of transactions and provides a basis for analyzing transaction flow.

[0161] For example, the payment record of 100,000 yuan from Company A (node ​​ID: E001) to Company B (node ​​ID: S002) on May 10, 2024 is extracted from the fund settlement subchain. At the same time, the corresponding invoice information is extracted from the invoice processing subchain, and the timestamp is uniformly converted to UTC time and then sorted by date and included in the transaction sequence.

[0162] S202. Convert the transaction sequence into a directed graph and construct the transaction network topology.

[0163] Among them, the directed graph is the mathematical expression of the transaction network, which intuitively presents the upstream and downstream transaction relationships between enterprises through the relationship between nodes and edges.

[0164] In some implementations, the coordinate information of nodes can be directly derived from the enterprise's positioning data in the 3D sharded chain, namely industry classification code (such as "1011" in ISIC Rev.4), hierarchical type (such as "1 = Tier 1 Supplier"), and business type (such as "I = Invoice Processing"). The direction of the edges strictly follows the principle of the payer pointing to the payee, and the weight is calculated by the proportion of the transaction amount to the payer's total transaction amount in the same period, using the formula: Transaction amount proportion = Single transaction amount / Payer's total transaction amount in the same period × 100%.

[0165] It should be noted that the topological structure of a directed graph can accurately reflect the flow of funds and dependencies in transactions, while the multidimensional attributes of node coordinates provide a data correlation basis for subsequent risk analysis in conjunction with industry and hierarchical characteristics.

[0166] For example, in a transaction sequence, Company C (core enterprise, level type 2) pays 800,000 yuan to Company D (distributor, level type 3), accounting for 20% of Company C's total transaction amount for the month. Then, an edge is formed in the directed graph from node C to node D, with a weight of 20%. The node coordinates are labeled with the industry code, level type and related business type of both parties.

[0167] S203, Store transaction networks and establish dynamic update mechanisms.

[0168] The graph database is used to efficiently store and manage the topology of the transaction network, and the dynamic update mechanism ensures that the network can reflect the latest transaction status in real time.

[0169] In some implementations, graph databases such as Neo4j and TigerGraph can be used to store directed graph data. Each node in the database corresponds to a record of enterprise attributes, and each edge corresponds to a record of transaction details. The update cycle is set according to the industry transaction frequency. For example, the retail industry is synchronized once per hour, and the heavy industry is synchronized once every 24 hours. When a new transaction record triggers a preset threshold (such as more than 500 new records in a single cycle), the instant update process is initiated.

[0170] In some implementations, graph databases (such as Neo4j) use an incremental synchronization mechanism with blockchain nodes, retrieving the block hash of new transactions from the blockchain every 10 minutes, verifying block integrity, and then updating the graph data. Visualization is achieved by calling the graph database's API to generate a dynamic topology graph, supporting node filtering by industry and level, and displaying real-time values ​​of the node's risk transmission coefficient.

[0171] It should be noted that the use of graph databases supports rapid querying and visualization of complex network relationships, while dynamic updates ensure the timeliness of the transaction network, enabling risk identification to be carried out based on the latest data.

[0172] For example, the transaction network of a certain automobile manufacturing industry is stored in the Neo4j database. The system automatically synchronizes the transaction data of the previous day at 2:00 AM every day. If 1,000 new transactions are added on a certain day due to promotional activities, an instant update is triggered, adding the node and edge information corresponding to the new transactions to the directed graph, and displaying the updated network structure through a visual interface.

[0173] Based on the above technical solution, by extracting preprocessed transaction data, converting it into a directed graph to construct a topology, and combining it with a graph database to achieve dynamic storage and updates, the transaction network constructed in this application can clearly and in real time present the transaction relationships and attribute characteristics between enterprises, and can more easily identify risk transmission paths.

[0174] In one possible implementation of the embodiments of this application, combined with Figure 2 ,like Figure 3 As shown, the above S3 can be implemented through the following S301, S302 and S303, which are explained in detail below:

[0175] S301. Calculate the degree centrality DC, proximity centrality CC, and betweenness centrality BC of each node in the transaction network.

[0176] Degree centrality measures the number of direct connections a node has with other nodes, reflecting the node's activity level in the transaction network; proximity centrality measures the reciprocal of the average distance from a node to all other nodes, reflecting the node's accessibility to other nodes in the network; and betweenness centrality measures the probability that a node is located on the shortest transaction path to other nodes, reflecting the node's bridging role in the transaction network.

[0177] In some implementations, the degree centrality can be calculated by weighting the proportion of transaction amount (edge ​​weights), and the formula is: DC = (sum of in-degree weights of nodes + sum of out-degree weights) / (total number of nodes in the network - 1).

[0178] To calculate proximity centrality, we first need to determine the shortest path from a node to all other nodes (based on the edge weight, i.e., the proportion of transaction amount; the higher the weight, the shorter the path). Then, we calculate it using the formula CC = (total number of nodes - 1) / sum of shortest path lengths.

[0179] The calculation of betweenness centrality requires traversing the shortest paths of all node pairs in the network, counting the number of times each node is an intermediate node in the shortest path, and then dividing by the total number of shortest paths of all node pairs.

[0180] It should be noted that the calculation of centrality must be based on the real-time updated transaction network topology to ensure the timeliness of the data; for isolated nodes (without any transaction connections) in the transaction network, their centrality can be uniformly set to 0.

[0181] For example, a core enterprise node has direct transactions with 5 suppliers and 3 distributors. The sum of its in-degree weights is 40% and the sum of its out-degree weights is 60%. There are 20 nodes in the network. Then its DC = (40% + 60%) / (20 - 1) ≈ 5.26%. The sum of the shortest path lengths from this node to the other 19 nodes is 38. Then its CC = 19 / 38 = 0.5. Among all 190 shortest paths between node pairs, 38 pass through this node. Then its BC = 38 / 190 = 0.2.

[0182] S302. Calculate the risk transmission coefficient R of each node according to the weighted summation formula.

[0183] Among them, the risk transmission coefficient is used to comprehensively evaluate the risk transmission capability of a node. The larger the value, the more likely the node is to become a key node for risk transmission.

[0184] In some implementations, the weighted summation formula is: R = w1 × DC + w2 × CC + w3 × BC, where w1, w2, and w3 are the weight coefficients of the centrality of each item, and w1 + w2 + w3 = 1. The weight coefficients can be set according to industry characteristics. For example, for the hierarchical manufacturing industry, the weight of the intermediary centrality can be increased (e.g., w3 = 0.4), while for the retail industry with frequent transactions, the weight of the degree centrality can be increased (e.g., w1 = 0.4). By default, a weight allocation of w1 = 0.3, w2 = 0.2, and w3 = 0.5 can be used.

[0185] It should be noted that the weighting coefficients can be optimized through machine learning using historical risk event data to make the risk transmission coefficients more closely match the actual risk transmission patterns. During the calculation process, it is necessary to ensure that the values ​​of each centrality have been standardized (e.g., converted to values ​​between 0 and 1) to avoid the results being affected by differences in units.

[0186] For example, if a node's DC is standardized to 0.6, CC to 0.5, and BC to 0.8, and the default weighting coefficients are used, then its risk transmission coefficient R = 0.3 × 0.6 + 0.2 × 0.5 + 0.5 × 0.8 = 0.18 + 0.1 + 0.4 = 0.68.

[0187] S303. Filter the risk transmission node set according to the preset threshold and output it.

[0188] Among them, the risk transmission node set refers to the set of nodes whose risk transmission coefficient is greater than a preset threshold, which is used for subsequent key investigation of risk points.

[0189] In some implementations, the preset threshold can be set based on the industry average risk transmission coefficient, for example, 1.5 times the industry average coefficient; alternatively, it can be calibrated using historical risk data, using the minimum risk transmission coefficient of nodes that have previously triggered risk transmission as the threshold. After the threshold is set, the system can automatically include nodes with risk transmission coefficients greater than the threshold into the risk transmission node set, and synchronize the node set to the tax compliance sub-chain of the three-dimensional sharded chain through blockchain smart contracts, making it available for query by regulatory nodes and enterprise nodes.

[0190] It should be noted that the preset threshold should be adjusted regularly according to the dynamic changes of the trading network. For example, when the trading activity in the network increases significantly, the threshold can be appropriately increased to focus on high-risk nodes. The output risk transmission node set should include node ID, node coordinates and various centrality values ​​to facilitate the tracing of the risk characteristics of the nodes.

[0191] For example, the preset threshold for the risk transmission coefficient of a certain industry is 0.6. After calculation, the coefficients of three nodes are 0.68, 0.72 and 0.85, respectively, all of which exceed the threshold. These three nodes constitute a risk transmission node set.

[0192] Based on the above technical solution, by calculating the centrality of nodes step by step, comprehensively evaluating the risk transmission coefficient, and screening key nodes, this application can accurately identify enterprise nodes with high risk transmission potential in the transaction network, providing a clear target for subsequent focus on risk point positioning, and improving the pertinence and efficiency of financial and tax risk prevention and control.

[0193] In one possible implementation of this application embodiment, the above-mentioned S4 specifically includes the following S401 to S403:

[0194] S401, Identifying risk points related to issuing false invoices.

[0195] The identification of risks related to issuing false invoices requires comparing data from multiple sharded blockchains to verify the consistency between invoice information and actual transactions. The core of this involves matching and verifying the invoice metadata with payment records, industry benchmarks, and tax compliance.

[0196] In some implementations, the specific operations include:

[0197] Extract invoice metadata from the invoice processing subchain of the business shard chain, including payer, transaction name, transaction quantity, and transaction unit price;

[0198] Obtain the corresponding payment record (actual payer, payment amount) from the funds settlement subchain;

[0199] Retrieve the input and output reconciliation relationship (input invoice categories) from the tax compliance sub-chain;

[0200] Extract raw material unit price range from industry segmentation chain.

[0201] Cross-validation identifies a risk point of fraudulent invoicing if any of the following conditions are met:

[0202] (1) The actual payer in the payment record is inconsistent with the payer on the invoice;

[0203] (2) The product name in the transaction is not related to the product category on the input invoice;

[0204] (3) The transaction price exceeds the industry's material price range.

[0205] It should be noted that production relevance is determined using word vector models and cosine similarity. For example, word vector models are used to convert the transaction product name and the product category of the input invoice into two word vector features. Then, a pre-defined similarity calculation formula and a preset similarity threshold (which is usually greater than 0.8) are used to determine whether there is a correlation between the two.

[0206] For example, an invoice shows that the payer is Company A, the traded product is "high-end chip" and the unit price is 5,000 yuan / piece. However, the fund settlement subchain shows that the actual payer is Company B, and the unit price range of the same model of chip in the industry sharding chain is 3,000-4,500 yuan. In this case, the node corresponding to the invoice is marked as a risk point of false invoicing.

[0207] S402, Risks related to inflated positioning costs and dual contracts.

[0208] Among them, the risk of inflated costs focuses on the degree of deviation between the transaction unit price and the production capacity and industry benchmark, while the risk of dual contracts focuses on the difference between the contract amount and the actual transaction amount. Both require cross-shard chain data linkage verification.

[0209] In some implementation methods, the steps for locating inflated costs are as follows:

[0210] Extract the unit price range of materials from the industry segment chain, and calculate the industry benchmark price (highest price + lowest price) / 2) and industry standard deviation based on the unit price range of materials;

[0211] Extract the transaction quantity and unit price from the invoice processing subchain;

[0212] Extract the agreed purchase quantity from the contract subchain;

[0213] The capacity utilization rate is calculated based on the transaction volume and agreed purchase volume: Transaction volume / Agreed purchase volume.

[0214] The degree of deviation is calculated using the formula "Cost Deviation Index = |Transaction Price - (Industry Benchmark Price × Capacity Utilization Rate)| / Industry Standard Deviation";

[0215] If the number of transactions exceeds the company's maximum storage capacity or the cost deviation index exceeds a preset threshold (e.g., 2), a risk point is marked.

[0216] The steps for locating dual contracts are as follows:

[0217] Extract the contract amount M from the contract subchain. c Signing time T c Extract the actual amount M from the invoice processing subchain. i Issuance time T i ;

[0218] Calculate the difference rate between the contract amount and the actual amount: Difference rate = |Mc - Mi| / Mc

[0219] Extract multiple payment records under the same contract from the fund settlement subchain and calculate the total payment amount M. total ;

[0220] A target node in the business sharding chain will be marked as a risk point for dual contracts if at least one of the following conditions is met:

[0221] (1) The difference rate is greater than the preset ratio;

[0222] (2) Total payment amount M total ≠ Contract Amount M c ;

[0223] (3) Signing time T c With the time of issuance T i The time difference is greater than the preset time difference.

[0224] It should be noted that the preset threshold for the cost deviation index should be adjusted according to industry volatility (e.g., the threshold for the commodity industry can be set to 3); the preset time difference should be determined according to the industry's regular cycle (e.g., 90 days).

[0225] It should be noted that in the three-dimensional sharded blockchain architecture of this application, each enterprise corresponds to a node in the blockchain network. This node is identified by a unique "node ID" and associated with industry classification code, hierarchical type code, and corresponding business category code to form node coordinates. Therefore, the target node refers to the participating entity in the blockchain network.

[0226] For example, a company's contract stipulates a purchase quantity of 1,000 units (capacity utilization rate of 100%), an industry benchmark price of 100 yuan, a standard deviation of 5 yuan, and an actual transaction unit price of 120 yuan. The calculated cost deviation index is |120-(100×1)| / 5 = 4>2. Furthermore, the transaction quantity of 1,500 units exceeds the maximum warehouse capacity of 1,200 units, so it is marked as a risk point of inflated costs. A contract amount of 1 million yuan corresponds to a total invoice amount of 800,000 yuan (difference rate of 20%), and the total payment is 900,000 yuan, all of which are inconsistent with the contract amount. This is marked as a risk point of dual contracts at the corresponding target node.

[0227] S403. Implement graded early warning based on the three-dimensional coordinates of all risk points.

[0228] Based on the three-dimensional coordinates of the risk point (such as industry code 1011, level type 2, business type I), the smart contract pushes the warning information to the corresponding enterprise node and regulatory node. Low risk (such as cost deviation index slightly exceeding the threshold) triggers a self-inspection reminder, medium risk (such as suspected false invoices) freezes the business sub-chain transaction permissions, and high risk is synchronized to the tax authorities and a traceability report is generated.

[0229] In some implementations, the risk classification criteria can be:

[0230] ①Low risk: If the cost deviation index is ≤2, or the difference rate is ≤10%, the system will send an SMS reminder to the enterprise to conduct a self-check within 7 days;

[0231] ② Medium risk: Nodes marked as having a risk of issuing false invoices or whose transfer pricing deviation is ≤30% will have their invoice processing subchain permissions frozen. Enterprises need to submit supporting documents to unfreeze the permissions.

[0232] ③ High risk: If the discrepancy rate between the two contracts is >30%, the information will be immediately synchronized with the tax authorities and a traceability report containing transaction hashes and node IDs will be generated.

[0233] It should be noted that consolidated revenue must be calculated based on the sum of the annual revenues of related companies within the hierarchical sharded blockchain. Related companies refer to parent and subsidiary companies with a shareholding ratio exceeding 25% or companies within the same group, and their information is stored in the core enterprise sub-chain of the hierarchical sharded blockchain. Consolidated revenue is the sum of the annual revenues declared by related companies in the tax compliance sub-chain. If a company belongs to multiple related groups, only the group it actually controls is counted. Warning information must include the specific data source of the risk point (such as a specific invoice code or contract number) to ensure traceability.

[0234] Based on the above technical solution, this application constructs a multi-dimensional, end-to-end financial and tax risk prevention and control mechanism by locating risk points such as false invoicing, inflated costs, and dual contracts step by step, and achieving precise early warning by combining three-dimensional coordinates. Cross-shard chain data comparison ensures the accuracy of risk identification, while the tiered early warning mechanism improves the efficiency of risk handling, effectively solving the problems of hidden risk points and difficulty in tracing the transmission of risks in traditional financial and tax management.

[0235] Furthermore, in this application, when the upstream and downstream related enterprises of the enterprise include multinational corporations, in order to address the hidden risks of transfer pricing and tax base erosion in cross-border transactions, the specific measures include:

[0236] Step 1: Mark enterprises in low-tax and high-tax zones.

[0237] Based on the taxpayer information (such as the tax rate of the place of registration and tax incentives) in the tax compliance sub-chain, enterprises involved in cross-border transactions are marked with tax zone attributes in the hierarchical shard chain, clearly distinguishing between enterprises in low-tax zones (such as enterprises registered in regions with tax rates below 10%) and enterprises in high-tax zones (such as enterprises registered in regions with tax rates above 25%).

[0238] Step 2: Calculate and compare profit margins.

[0239] Based on the operating profit and operating cost data stored in the hierarchical sharded chain, the profit margin R of enterprises in low-tax areas is calculated. low (R low = Operating profit / Operating cost) and the profit margin R of companies in high-tax areas high ;

[0240] Enterprises in low-tax zones and enterprises in high-tax zones are classified according to industry type codes;

[0241] Simultaneously, the profit margins of all comparable independent companies (non-affiliated parties) in the industry shard chain are queried to obtain the median value R. med This serves as a benchmark. The comparable independent enterprises refer to all other enterprises within the same category that share the same industry type code as both low-tax and high-tax enterprises. For example, assuming low-tax enterprises include A, B, and C, and high-tax enterprises include E, F, and G, and A shares the same industry type code as E and F, then when judging low-tax enterprise A, the median profit margins of E and F are considered.

[0242] Step 3: Determine the risk of abnormal profit margin.

[0243] When the profit margin R of enterprises in low-tax zones low >α1×R median (where α1 is a preset proportional coefficient, such as 1.2), or the profit margin R of enterprises in high-tax areas. high <α2×R medianWhen α2 is a preset proportional coefficient, such as 0.8, the corresponding enterprise node in the hierarchical sharding chain is marked as a transfer pricing risk point.

[0244] Step 4: Verify the proportion of related service fees.

[0245] Extract service fee data paid by high-tax zone enterprises to low-tax zone enterprises from the tax compliance subchain, calculate the proportion of this fee to the consolidated revenue of related enterprises (the total operating revenue of low-tax zone and high-tax zone enterprises within the same group), and if it exceeds a preset percentage (such as 5%), then mark the corresponding node in the tax compliance subchain as a transfer pricing risk point.

[0246] It should be noted that the values ​​of α1 and α2 can be determined with reference to the OECD transfer pricing guidelines and domestic anti-tax avoidance regulations.

[0247] The above primarily describes the solutions of the embodiments of this application from the perspective of device implementation. It is understood that each device, such as a blockchain-based financial and tax management device, includes at least one of the hardware structures and software modules corresponding to the execution of each function in order to achieve the above-mentioned functions. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0248] This application embodiment can divide the blockchain-based financial and tax management device into functional units according to the above method example. For example, each function can be divided into separate functional units, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0249] When using integrated units, Figure 5 A possible structural diagram of the blockchain-based financial and tax management device (referred to as blockchain-based financial and tax management device 50) involved in the above embodiments is shown. The blockchain-based financial and tax management device 50 includes a processing unit 501 and a communication unit 502, and may also include a storage unit 503. Figure 5 The structural diagram shown can be used to illustrate the structure of the blockchain-based financial and tax management device involved in the above embodiments.

[0250] when Figure 5 The schematic diagram shown illustrates the structure of the blockchain-based financial and tax management device involved in the above embodiments. The processing unit 501 is used to control and manage the operation of the blockchain-based financial and tax management device, the communication unit 502 is used for the blockchain-based financial and tax management device to communicate with other devices, and the storage unit 503 is used to store the program code and data of the blockchain-based financial and tax management device.

[0251] For example, communication unit 502 is used to obtain invoice metadata from the invoice processing subchain of the business segment chain, obtain corresponding payment records from the fund settlement subchain, retrieve the input and output reconciliation relationship from the tax compliance subchain, and extract raw material unit price range from the industry segment chain.

[0252] The processing unit 501 is used to execute the location logic of the risk point of false invoice based on the multi-shard chain data obtained by the communication unit 502, including verifying the consistency between the invoice payer and the actual payer, the production relevance between the transaction product name and the product category of the input invoice, and the matching degree between the transaction unit price and the industry material unit price range. If any condition is not met, the risk point is marked.

[0253] In one possible implementation, the processing unit 501 is also used to calculate the cost deviation index. If the number of transactions exceeds the enterprise's maximum storage capacity or the cost deviation index exceeds a preset threshold, then the risk point of inflated costs is marked.

[0254] In one possible implementation, the communication unit 502 is also used to obtain the maximum warehouse capacity data and business license registration information of the regulated enterprise itself from the hierarchical shard chain, and extract data such as the agreed purchase quantity and contract amount from the contract sub-chain; the processing unit 501 is also used to execute the location logic of the risk point of the dual contract based on the hierarchical shard chain and contract sub-chain data obtained by the communication unit 502, including calculating the difference rate between the contract amount and the actual amount, comparing whether the total payment amount of the same contract is consistent with the contract amount, and marking the risk point if there is an anomaly.

[0255] The processing unit 501 can be a processor or a controller, and the communication unit 502 can be a communication interface, transceiver, transceiver circuit, transceiver device, etc. The term "communication interface" is a general term and may include one or more interfaces. The storage unit 503 can be a memory. When the blockchain-based financial and tax management device 50 is a chip, the processing unit 501 can be a processor or a controller, and the communication unit 502 can be an input interface and / or an output interface, pins, or circuits, etc. The storage unit 503 can be a storage unit within the chip (e.g., a register, cache, etc.) or a storage unit located outside the chip (e.g., read-only memory (ROM), random access memory (RAM, etc.)).

[0256] The communication unit can also be called a transceiver unit. The antenna and control circuit with transceiver functions in the blockchain-based financial and tax management device 50 can be considered as the communication unit 502 of the blockchain-based financial and tax management device 50, and the processor with processing functions can be considered as the processing unit 501 of the blockchain-based financial and tax management device 50. Optionally, the device in the communication unit 502 that implements the receiving function can be considered as a communication unit, which is used to execute the receiving steps in the embodiments of this application. The communication unit can be a receiver, a receiver circuit, etc. The device in the communication unit 502 that implements the transmitting function can be considered as a transmitting unit, which is used to execute the transmitting steps in the embodiments of this application. The transmitting unit can be a transmitter, a transmitter, a transmitting circuit, etc.

[0257] Figure 5 If the integrated units in the process are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of software products. These computer software products are stored in a storage medium and include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. Storage media for storing computer software products include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0258] Figure 5 The units in the process can also be called modules; for example, a processing unit can be called a processing module.

[0259] This application also provides a hardware structure diagram of a blockchain-based financial and tax management device (referred to as blockchain-based financial and tax management device 60), see [link to diagram]. Figure 6 The blockchain-based financial and tax management device 60 includes a processor 601, and optionally, a memory 602 connected to the processor 601.

[0260] In the first possible implementation, see Figure 6 The blockchain-based financial and tax management device 60 also includes a transceiver 603. The processor 601, memory 602, and transceiver 603 are connected via a bus. The transceiver 603 is used to communicate with other devices or communication networks. Optionally, the transceiver 603 may include a transmitter and a receiver. The device in the transceiver 603 that implements the receiving function can be considered as a receiver, which is used to perform the receiving steps in the embodiments of this application. The device in the transceiver 603 that implements the transmitting function can be considered as a transmitter, which is used to perform the transmitting steps in the embodiments of this application.

[0261] Based on the first possible implementation method Figure 6 The structural diagram shown can be used to illustrate the structure of the blockchain-based financial and tax management device involved in the above embodiments.

[0262] in, Figure 6 This can also be illustrated by a system chip in a blockchain-based financial and tax management device. In this case, the actions performed by the aforementioned blockchain-based financial and tax management device can be implemented by this system chip. The specific actions performed can be found above and will not be repeated here.

[0263] In implementation, each step of the method provided in this embodiment can be completed by integrated logic circuits in the processor or by instructions in software form. The steps of the method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0264] The processor in this application may include, but is not limited to, at least one of the following: a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a microcontroller unit (MCU), or an artificial intelligence processor, etc., and other computing devices that run software. Each computing device may include one or more cores for executing software instructions to perform calculations or processing. The processor may be a separate semiconductor chip or integrated with other circuits into a single semiconductor chip. For example, it may be integrated with other circuits (such as encoding / decoding circuits, hardware acceleration circuits, or various bus and interface circuits) to form a System-on-a-Chip (SoC), or it may be integrated as a built-in processor within an ASIC. The ASIC with the integrated processor may be packaged separately or together with other circuits. In addition to the cores for executing software instructions to perform calculations or processing, the processor may further include necessary hardware accelerators, such as field-programmable gate arrays (FPGAs), PLDs (programmable logic devices), or logic circuits that implement dedicated logic operations.

[0265] The memory in the embodiments of this application may include at least one of the following types: read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions; random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions; or electrically erasable programmable-only memory (EEPROM). In some scenarios, the memory may also be a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0266] This application also provides a computer-readable storage medium including instructions that, when run on a computer, cause the computer to perform any of the methods described above.

[0267] This application also provides a chip including a processor and an interface circuit. The interface circuit is coupled to the processor. The processor is used to run computer programs or instructions to implement the above-described method. The interface circuit is used to communicate with other modules outside the chip.

[0268] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks (SSDs)).

[0269] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, the disclosure, and the appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0270] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely illustrative descriptions of the application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and variations.

Claims

1. A blockchain-based financial and tax management method, characterized in that, include: A three-dimensional sharding chain is constructed based on blockchain technology; the three-dimensional sharding chain includes an industry sharding chain, a hierarchical sharding chain, and a business sharding chain. Draw the transaction network based on the 3D sharded chain; Calculate the centrality of each node in the transaction network and output the risk transmission node set; Based on the risk transmission node set, the data of each shard chain in the three-dimensional shard chain are compared to locate the risk points; The risks mentioned include issuing false invoices, inflating costs, and using dual contracts (one for official purposes and another for private purposes). Risk warnings are issued based on the three-dimensional coordinates of risk points.

2. The blockchain-based financial and tax management method according to claim 1, characterized in that, The three-dimensional sharded chain rendering transaction network includes: Extract all smart contract interaction records from the 3D sharded chain. The interaction records include transaction timestamps, node IDs of both parties to the transaction, transaction type, transaction amount, and currency type. Convert the timestamps to a unified time zone and sort the interaction records in chronological order to construct a transaction sequence; The transaction sequence is converted into a directed graph to obtain a transaction network; wherein, the nodes of the transaction network represent enterprises, and the node coordinates include industry classification code and hierarchical type code, the edges of the transaction network represent transaction events, the direction is from the payer to the payee, and the weight is the proportion of the transaction amount.

3. The blockchain-based financial and tax management method according to claim 2, characterized in that, When drawing the transaction network, the topology is updated by synchronizing the newly added value flow trajectory and payment records on the chain at fixed intervals, and the transaction network is stored in a graph database to enable real-time querying and visualization.

4. The blockchain-based financial and tax management method according to claim 1, characterized in that, The process of obtaining the risk transmission node set includes: Calculate the degree centrality DC, proximity centrality CC, and betweenness centrality BC for each node; The risk transmission coefficient R for each node is calculated using the weighted summation formula: R = w1 × DC + w2 × CC + w3 × BC; where w1, w2, and w3 represent the weight coefficients of each item. Nodes with a risk transmission coefficient greater than a preset threshold are added to the risk transmission node set and output.

5. A blockchain-based financial and tax management method according to claim 1, characterized in that, The industry sharding chain includes each sub-chain obtained by dividing each upstream and downstream related enterprise according to international standard industry classification, and each sub-chain contains an industry type code; the industry sharding chain is used to store industry benchmark data, and the industry precise data includes material unit price range, industry average profit margin, compliance transaction cycle, and product upstream and downstream relationship; The hierarchical sharding chain includes supplier sub-chains, core enterprise sub-chains, and distributor sub-chains, and each sub-chain contains a hierarchical type code. The hierarchical sharding chain is used to record the hierarchical attributes and historical transaction records of the transaction subject and supports the rationality verification of transactions between hierarchical levels. The business shard chain includes an invoice processing subchain, a fund settlement subchain, a tax compliance subchain, and a contract subchain. Each subchain contains a business type code. The business shard chain is used to perform closed-loop verification of the tax business flow, ensuring that invoice metadata, payment records, declaration data, and basic contract information are cross-verified in the distributed ledger.

6. The blockchain-based financial and tax management method according to claim 5, characterized in that, The method for identifying the risk points of false invoices includes: The invoice metadata in the invoice processing subchain is linked with the payment records in the fund settlement subchain, the input and output reconciliation relationship in the tax compliance subchain, and the material unit price range in the industry segment chain; the invoice metadata includes the payer, the name of the traded item, the quantity of the traded item, and the unit price of the traded item. The target node in the invoice processing subchain will be marked as a risk point of fraudulent invoicing if at least one of the following conditions is met: (1) The actual payer in the payment record is inconsistent with the payer in the invoice metadata; (2) The transaction product name in the invoice metadata and the product category of the input invoice in the input-output reconciliation relationship have no production relevance; the production relevance is determined by word vector model and cosine similarity. (3) The transaction unit price in the invoice metadata is not within the material unit price range.

7. A blockchain-based financial and tax management method according to claim 5, characterized in that, The method for identifying the risk points of inflated costs includes: Extract the unit price range and industry standard deviation of materials from the industry segmentation chain; Extract invoice metadata from the invoice processing subchain, including the transaction name, transaction quantity, and transaction unit price; The industry benchmark price is obtained based on the unit price range of the material; the industry benchmark price is the average of the maximum and minimum values ​​in the unit price range of the material. Extract the agreed purchase quantity from the contract subchain, and calculate the ratio of the transaction quantity to the agreed purchase quantity to obtain the capacity utilization rate; The cost deviation index is calculated using the following formula: Cost Deviation Index = |Transaction Price - (Industry Benchmark Price × Capacity Utilization Rate)| / Industry Standard Deviation; When the cost deviation index exceeds the preset cost deviation threshold, the target node in the invoice subchain is marked as a risk point of inflated costs.

8. A blockchain-based financial and tax management method according to claim 5, characterized in that, The risk identification method for the aforementioned dual contracts includes: Extract contract data and invoice data from the business segment chain. The contract data includes the contract amount M. c Signing time T c The invoice data includes the actual amount M. i Issuance time T i ; Calculate the difference rate between the contract amount and the actual amount: Difference rate = |M c -M i | / M c ; Extract multiple payment records under the same contract in the fund settlement subchain and calculate the total payment amount Mtotal; A target node in the business sharding chain will be marked as a risk point for dual contracts if at least one of the following conditions is met: (1) The difference rate is greater than the preset ratio; (2) Total payment amount M total ≠ Contract Amount M c ; (3) Signing time T c With the time of issuance T i The time difference is greater than the preset time difference.

9. A blockchain-based financial and tax management method according to claim 5, characterized in that, When the upstream and downstream related enterprises of the enterprise include multinational corporations, the risk point also includes transfer pricing, and the method for locating the risk point of transfer pricing includes: Based on the taxpayer information in the tax compliance subchain, enterprises in low-tax areas and enterprises in high-tax areas are marked in the hierarchical segmented chain; Based on the operating profit and operating cost data in the hierarchical sharding chain, calculate the profit margin R of enterprises in low-tax areas. low Profit margin R of companies in high-tax zones high ; Enterprises are categorized based on their industry type codes in high-tax and low-tax zones, and the median profit margin R of enterprises with the same industry type code is retrieved from the industry sharding chain. med ; When the profit margin R of enterprises in low-tax zones low >α1×R med or the profit margin R of companies in high-tax zones high <α2×R med At that time, the target node in the hierarchical sharding chain is marked as a transfer pricing risk point; where α1 and α2 represent preset proportional coefficients; When the service fee in the tax compliance subchain exceeds a preset percentage of the company's consolidated revenue, the target node in the tax compliance subchain will be marked as a transfer pricing risk point.

10. A blockchain-based financial and tax management system, characterized in that, The system includes a blockchain construction module, a transaction network mapping module, a centrality calculation module, a risk point location module, and a risk warning module; among which... The blockchain construction module is used to construct a three-dimensional sharded chain based on blockchain technology, which includes industry sharded chains, hierarchical sharded chains, and business sharded chains. The transaction network drawing module is used to draw the transaction network based on the three-dimensional sharded chain; The centrality calculation module is used to calculate the centrality of each node in the transaction network and output the risk transmission node set; The risk point location module is used to compare the data of each shard chain in the three-dimensional shard chain based on the risk transmission node set, and locate risk points including false invoices, inflated costs and dual contracts; The risk warning module is used to provide risk warnings based on the three-dimensional coordinates of the risk points.

Images