An intelligent settlement method based on a knowledge graph

Abstract

The application discloses an intelligent account distribution settlement method based on a knowledge graph, which comprises the following steps: obtaining transaction orders, payment flow, account distribution subjects, contract rules, after-sales refunds, invoices, tax affairs and settlement account data to obtain a basic data set; constructing an account distribution settlement knowledge graph and a settlement meta-path instance set; inputting the same into an improved knowledge graph heterogeneous graph attention network model to perform fund direction constraint relationship gating, double-layer attention and conflict perception fusion to obtain subject embedding representation, settlement relationship weight, path semantic weight and abnormal risk weight; performing account distribution proportion decoding, account reachability verification and proportion path joint sorting based on model output to generate account distribution settlement results and complete abnormal attribution. The application relates to the technical field of intelligent account distribution settlement and realizes automatic account distribution, path generation and abnormality verification of multi-subject transactions.

Description

Technical Field

[0001] This invention relates to the field of intelligent revenue sharing and settlement technology, specifically to an intelligent revenue sharing and settlement method based on knowledge graphs. Background Technology

[0002] With the development of platform economy, aggregated payment, digital transactions, and multi-entity collaborative business, the transaction settlement process no longer involves only a single payee, but also multiple participating entities such as platforms, merchants, service providers, channel providers, suppliers, and promoters. These different entities typically have complex relationships involving contract terms, fee rules, preferential treatment, refund offsetting, tax invoicing, and account clearing. The settlement results must simultaneously satisfy the requirements of transaction amount consistency, contract rule applicability, account accessibility, and verifiable fund closure.

[0003] Existing revenue-sharing settlement methods largely rely on pre-configured rule templates or fixed-ratio calculation methods, which are suitable for scenarios with clear rules, a small number of entities, and simple transaction chains. However, in business scenarios with multiple entities, contracts, fee rates, and multiple refund events, fixed rules are difficult to accurately express the heterogeneous relationships between entities, and also difficult to dynamically adjust the revenue-sharing results based on order status, contract status, refund status, invoice status, and account status. When the transaction chain changes, new revenue-sharing entities are added, contract rules are adjusted, or after-sales events are triggered, traditional methods usually require manual modification of rules, re-verification of accounts, and anomaly investigation, resulting in poor processing efficiency and consistency.

[0004] Knowledge graphs can express the relationships between transaction orders, payment records, contract terms, revenue sharing entities, settlement accounts, and after-sales events. However, if only relationship queries are performed using knowledge graphs, it is still difficult to determine the degree of impact of different relationship paths on revenue sharing ratios, settlement accounts, and anomaly risks. Although existing graph neural network models can learn representations of graph-structured data, ordinary graph attention models or heterogeneous graph attention models often do not fully consider the constraints of fund direction, contract rules, refund offsetting, account reachability, and fund closed-loop verification in revenue sharing and settlement scenarios. This can easily lead to problems such as inaccurate identification of revenue sharing entities, unstable settlement path matching, and difficulty in locating the source of anomalies.

[0005] Therefore, how to provide an intelligent revenue sharing and settlement method based on knowledge graphs is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] One objective of this invention is to propose an intelligent revenue sharing and settlement method based on knowledge graphs. This invention fully utilizes knowledge graphs, heterogeneous graph attention networks, and intelligent settlement data processing technologies. It details the process of constructing a revenue sharing and settlement knowledge graph from multiple sources of data, including transaction orders, payment records, revenue sharing entities, contract rules, refund and after-sales service, invoices and taxes, and settlement accounts. The invention also employs an improved knowledge graph heterogeneous graph attention network model to perform gating of fund direction constraints, two-layer attention calculation, settlement conflict perception fusion, and joint ranking of proportional paths. This method possesses advantages such as strong multi-entity relationship expression capabilities, high adaptability to revenue sharing rules, accurate identification of abnormal settlements, and verifiable settlement paths.

[0007] According to an embodiment of the present invention, an intelligent revenue sharing and settlement method based on knowledge graphs includes the following steps: S1. Obtain transaction orders, payment records, accounting entities, contract rules, refund and after-sales service, invoice tax and settlement account data, and perform field standardization, entity alignment and time series organization to obtain the basic dataset; S2. Extract order, payment, entity, contract, rule, event, tax and account nodes from the basic dataset, and construct a split settlement knowledge graph based on transaction ownership, fund flow, contract constraints, rule application, refund reduction, invoice tax and account settlement relationships; S3. Based on the accounting and settlement knowledge graph, construct the transaction entity identification path, contract constraint path, refund offset path, tax invoice path, account reachability path, and fund closed-loop verification path, extract and filter path instances to obtain a set of settlement meta-path instances; S4. Input the knowledge graph of revenue sharing and settlement and the set of settlement meta-path instances into the improved knowledge graph heterogeneous graph attention network model, and perform fusion of fund direction constraint relationship gating, two-layer attention and settlement conflict perception to obtain subject embedding representation, settlement relationship weight, path semantic weight and abnormal risk weight. S5. Based on the subject embedding representation, settlement relationship weight, path semantic weight, abnormal risk weight and contract rules, perform revenue sharing ratio decoding, account accessibility verification and joint sorting of ratio paths to obtain intelligent revenue sharing ratio, revenue sharing settlement path and account mapping results. S6. Generate settlement results based on the intelligent revenue sharing ratio, revenue sharing settlement path and account mapping results, and verify and attribute them in conjunction with payment flow, contract rules, refund and after-sales service, invoice taxation, account clearing and abnormal risk weights to obtain settlement verification results and abnormal settlement prompt results.

[0008] Optionally, step S2 includes the following steps: S21. Extract order, payment, entity, contract, rule, event, tax and account objects from the basic dataset to obtain a heterogeneous node set; S22. Extract relationships based on payment correspondence, transaction ownership, revenue sharing, rule constraints, refund offsetting, tax matching, and account binding to obtain a heterogeneous set of relationships; S23. Construct knowledge graph triples based on the heterogeneous node set and heterogeneous relationship set, and add business roles, funding directions, rule status, event status and account settlement tags to obtain graph relationship data; S24. Construct a revenue-sharing settlement knowledge graph based on the graph relationship data, and clean up duplicate nodes, conflicting relationships, isolated relationships and invalid account relationships to obtain the revenue-sharing settlement knowledge graph.

[0009] Optionally, step S3 includes the following steps: S31. Construct the six types of settlement meta-paths as described in claim 1 based on the node types and relationship types in the split settlement knowledge graph to obtain a set of candidate settlement meta-paths; S32. Traverse the accounting and settlement knowledge graph based on the candidate settlement meta-path set to obtain the candidate settlement meta-path instance set; S33. Filter based on node role completeness, fund direction consistency, rule applicability, refund relevance, tax account matching, and account reachability to obtain a set of valid settlement metapath instances; S34. Calculate the connection contribution of each path based on the set of valid settlement metapath instances to obtain the set of settlement metapath instances.

[0010] Optionally, step S4 includes the following steps: S41. Vector encode the node attributes, relation attributes, and settlement semantic labels in the revenue sharing and settlement knowledge graph to obtain the initial feature representation of the heterogeneous graph; S42. Based on the initial feature representation of the heterogeneous graph and the set of settlement element path instances, perform fund direction constraint relationship gating processing to obtain relationship gating features; S43. Calculate node-level attention within the path based on relational gating features to obtain node contribution weights; S44. Perform semantic-level attention calculation between paths based on the node contribution weights to obtain the path semantic weights; S45. Based on the node contribution weight and path semantic weight, perform settlement conflict perception fusion to obtain the subject embedding representation, settlement relationship weight and abnormal risk weight.

[0011] Optionally, step S42 includes the following steps: S421. Extract relationship type, funding direction, contract, refund, tax and account features based on the initial feature representation of the heterogeneous graph to obtain the settlement relationship context feature set; S422. Generate relation gating coefficients based on the settlement relation context feature set; S423. Adjust the message transmission strength of fund, contract, refund, tax and account relationships according to the relationship gating coefficient to obtain the relationship adjustment message characteristics; S424. Based on the relationship adjustment message characteristics, perform neighborhood information transmission and path aggregation to obtain relationship gating characteristics.

[0012] Optionally, step S43 includes the following steps: S431. Determine the set of neighbor nodes of the current order node under different settlement meta paths based on the relation gating features, and obtain the path neighbor candidate set; S432. Perform attention matching based on the path neighbor candidate set, relationship gating features, and current order node features to obtain the attention score of nodes within the path; S433. Based on the attention scores of nodes within the path, the target neighbor nodes are weighted and aggregated to obtain the aggregated representation of nodes within the path. S434. Determine the contribution level of neighboring nodes based on the node aggregation representation within the path, and obtain the node contribution weight.

[0013] Optionally, S44 includes the following steps: S441. Aggregate the path representations of each settlement element path according to the node contribution weight to obtain a multi-path settlement representation set; S442. Construct proportion, account, and risk query vectors based on the multi-path settlement representation set, and calculate semantic relevance to obtain multi-task semantic attention scores; S443. Weighted fusion is performed based on the multi-task semantic attention scores to obtain semantic representations of proportion, account, and risk. S444. Determine the degree of influence of each path based on the proportion, account, and risk semantic representation to obtain the path semantic weight.

[0014] Optionally, S45 includes the following steps: S451. Generate an order-level settlement fusion representation based on node contribution weight and path semantic weight, and extract subject, rule, event, tax, account and closed-loop features to obtain a settlement conflict identification feature set; S452. Based on the settlement conflict identification feature set, calculate the rules, events, tax and account conflict intensity to obtain the multi-source settlement conflict intensity set; S453. Generate a risk gating vector based on the set of multi-source settlement conflict intensity, and perform dimensional weighted suppression on the order-level settlement fusion representation to obtain the risk-aware settlement representation; S454. Generate subject embedding representation, settlement relationship weight and abnormal risk weight based on risk perception settlement representation.

[0015] Optionally, step S5 includes the following steps: S51. Determine the candidate revenue sharing subject set based on the subject embedding representation and settlement relationship weight, and extract subject roles, rule associations, account bindings and settlement status to obtain candidate revenue sharing object data; S52. Construct the main body ratio score based on the candidate revenue sharing object data, settlement relationship weight and path semantic weight, and perform ratio, contract, refund and tax constraint processing to obtain the candidate revenue sharing ratio set; S53. Verify the candidate revenue sharing ratio set, settlement account data and account reachable path to obtain the candidate revenue sharing settlement path set; S54. Construct proportional penalty items, path blocking items, and rule correction items based on abnormal risk weights, and construct a proportional path joint scoring matrix; S55. Perform joint scoring, conflict suppression, and reachability sorting based on the proportional path joint scoring matrix to obtain the intelligent revenue sharing ratio, revenue sharing settlement path, and account mapping results.

[0016] Optionally, step S6 includes the following steps: S61. Generate a detailed breakdown of the revenue sharing based on the intelligent revenue sharing ratio, revenue sharing settlement path, and account mapping results, and obtain the settlement results; S62. Perform a consistency check between the settlement result and the payment transaction data to obtain the payment consistency check result; S63. Perform rule verification based on the settlement results, contract rule data, and refund and after-sales data to obtain the rule consistency verification result; S64. Based on the settlement results, invoice tax data, account clearing data, and fund closed-loop verification path, perform account consistency verification to obtain the tax account verification result; S65. Based on the abnormal risk weight and each verification result, perform abnormal attribution to obtain the settlement verification result and abnormal settlement prompt result.

[0017] The beneficial effects of this invention are as follows: By constructing a knowledge graph for revenue sharing and settlement, this invention unifies data such as transaction orders, payment records, revenue sharing entities, contract rules, refunds and after-sales service, invoices and taxes, and settlement accounts into nodes and relationships. This transforms settlement information, originally scattered across order, payment, contract, tax, and account systems, into a relational and traceable graph structure. Compared to revenue sharing methods that rely on single-table rule matching, this invention can more completely express the relationships between multiple entities, contracts, accounts, and events, providing a stable data foundation for complex revenue sharing and settlement.

[0018] This invention transforms key business relationships in revenue sharing into a set of settlement meta-path instances that can be used for model inference by constructing transaction entity identification paths, contract constraint paths, refund offset paths, tax invoice paths, account accessibility paths, and fund closed-loop verification paths. Compared to methods that calculate revenue sharing results solely based on order fields or fixed rate rules, this invention can identify key factors affecting revenue sharing entities, revenue sharing ratios, settlement accounts, and abnormal risks from different settlement relationship paths, thereby improving revenue sharing inference capabilities in complex transaction scenarios.

[0019] This invention employs an improved knowledge graph heterogeneous graph attention network model for gating fund direction constraints. This enables the model to distinguish the strength of different relationships during message transmission, such as transaction ownership, fund flow, contractual constraints, refund offsets, invoice and tax matters, and account settlement. Compared to ordinary heterogeneous graph attention networks, this invention incorporates fund direction, rule state, event state, and account settlement state as constraint factors in node representation learning, reducing the interference of irrelevant relationships on the accounting results and improving the accuracy of accounting entity identification and settlement relationship weight calculation.

[0020] This invention employs a two-layer reasoning approach, combining node-level attention within a path and semantic-level attention between paths. It first identifies the contribution of different nodes along the same settlement path to the current order, then assesses the impact of different settlement meta-paths on the revenue sharing ratio, account path, and anomaly risk. Compared to single-layer graph attention calculation methods, this invention simultaneously considers local node contributions and global path semantics, ensuring that revenue sharing results are not solely dependent on a single rule or relationship, but rather generated by integrating multi-dimensional factors such as the transaction entity, contract rules, refund events, tax accounts, and fund closure.

[0021] This invention generates abnormal risk weights through settlement conflict perception and fusion, and utilizes these abnormal risk weights to participate in revenue sharing ratio decoding, account accessibility verification, and joint ranking of ratio paths. Compared to the method of first generating revenue sharing results and then manually verifying them, this invention can detect contract rule conflicts, refund reduction conflicts, tax account conflicts, and fund closure conflicts in advance during the revenue sharing ratio and settlement path generation stages, thereby reducing the possibility of abnormal path mismatches and improving the executability and verifiability of revenue sharing settlement results.

[0022] This invention uses a proportional path joint scoring matrix to jointly score, suppress conflicts, and rank the reachability of candidate revenue sharing ratios and candidate revenue sharing settlement paths, thereby synchronously determining the revenue sharing ratio, fund flow path, and settlement account mapping results. Compared to methods that separately handle ratio calculation, account selection, and anomaly verification, this invention can reduce inconsistencies between revenue sharing ratios and account paths, and improve the automation capabilities and settlement loop consistency in multi-entity settlement scenarios.

[0023] This invention combines the abnormal risk weights with the results of payment consistency verification, rule consistency verification, and tax account consistency verification to generate separate settlement verification results and abnormal settlement prompts. Compared to traditional reconciliation methods that only provide verification failure results, this invention can further pinpoint the sources of anomalies corresponding to payment amount conflicts, contract rule conflicts, refund reduction conflicts, tax account conflicts, and fund loop conflicts, facilitating subsequent settlement corrections and anomaly handling. Attached Figure Description

[0024] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of an intelligent revenue sharing and settlement method based on knowledge graphs proposed in this invention; Figure 2 This is a schematic diagram of the improved knowledge graph heterogeneous graph attention network model proposed in this invention; Figure 3 This is a schematic diagram of the proportional path joint sorting and anomaly settlement verification process proposed in this invention. Detailed Implementation

[0025] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0026] refer to Figures 1-3 A knowledge graph-based intelligent revenue sharing and settlement method includes the following steps: S1. Obtain transaction orders, payment records, accounting entities, contract rules, refund and after-sales service, invoice tax and settlement account data, and perform field standardization, entity alignment and time series organization to obtain the basic dataset; S2. Extract order, payment, entity, contract, rule, event, tax and account nodes from the basic dataset, and construct a split settlement knowledge graph based on transaction ownership, fund flow, contract constraints, rule application, refund reduction, invoice tax and account settlement relationships; S3. Based on the accounting and settlement knowledge graph, construct the transaction entity identification path, contract constraint path, refund offset path, tax invoice path, account reachability path, and fund closed-loop verification path, extract and filter path instances to obtain a set of settlement meta-path instances; S4. Input the knowledge graph of revenue sharing and settlement and the set of settlement meta-path instances into the improved knowledge graph heterogeneous graph attention network model, and perform fusion of fund direction constraint relationship gating, two-layer attention and settlement conflict perception to obtain subject embedding representation, settlement relationship weight, path semantic weight and abnormal risk weight. S5. Based on the subject embedding representation, settlement relationship weight, path semantic weight, abnormal risk weight and contract rules, perform revenue sharing ratio decoding, account accessibility verification and joint sorting of ratio paths to obtain intelligent revenue sharing ratio, revenue sharing settlement path and account mapping results. S6. Generate settlement results based on the intelligent revenue sharing ratio, revenue sharing settlement path and account mapping results, and verify and attribute them in conjunction with payment flow, contract rules, refund and after-sales service, invoice taxation, account clearing and abnormal risk weights to obtain settlement verification results and abnormal settlement prompt results.

[0027] In this embodiment, S1 specifically includes: acquiring transaction orders, payment records, accounting entities, contract rules, refund and after-sales service, invoice tax and settlement account data, performing field standardization, entity alignment and time sequence organization to obtain the basic dataset.

[0028] Transaction order data includes order number, order amount, order status, transaction product or service identifier, order generation time, order completion time, and the identifier of the merchant to whom the order belongs.

[0029] Payment transaction data includes payment transaction number, order number, payment amount, payment channel, payment status, payment completion time, payment account identifier, and payment fee information.

[0030] The revenue sharing entity data includes entity number, entity type, entity role, entity status, business chain to which it belongs, revenue sharing participation identifier, and entity settlement priority.

[0031] Contract rules data includes contract number, applicable parties, contract validity status, fee rate rules, upper limit of revenue sharing ratio, lower limit of revenue sharing ratio, settlement cycle rules, and special deduction rules.

[0032] Refund and after-sales data includes after-sales event number, original order number, refund amount, refund status, refund initiator, refund responsible party, refund completion status, and refund reduction method.

[0033] Invoice tax data includes invoice number, invoice issuer, invoice recipient, tax rate type, tax amount, invoice status, invoice-related orders, and tax matching status.

[0034] Settlement account data includes account number, account owner, account status, account type, clearing channel, account availability, frozen status, and clearing result status.

[0035] Field standardization is used to unify field names, field types, and field value meanings across different systems. It unifies the amount field as a numeric field and unifies order status, payment status, contract status, invoice status, and account status as enumerable status fields.

[0036] The entity alignment process is used to map the merchant ID, contract entity ID, account entity ID, and invoicing entity ID of the same sub-account entity in the transaction system, contract system, account system, and tax system to a unified entity identifier.

[0037] Time-series sorting is used to sort data according to order generation time, payment completion time, refund completion time, invoice generation time, and account settlement time, forming a basic dataset that can represent the order of transaction settlement.

[0038] Each piece of data in the basic dataset retains the source system identifier and data update time identifier, which facilitates the identification of the source of the anomaly during subsequent anomaly attribution.

[0039] In this embodiment, S2 specifically includes: extracting order, payment, entity, contract, rule, event, tax and account nodes from the basic dataset, and constructing a split settlement knowledge graph based on transaction ownership, fund flow, contract constraints, rule application, refund reduction, invoice tax and account settlement relationships.

[0040] Order nodes are used to represent specific transaction orders. Node attributes include order number, order amount, order status, transaction time, and order owner.

[0041] Payment nodes are used to represent payment transactions. Node attributes include transaction number, payment amount, payment channel, payment status, and payment completion time.

[0042] The main node is used to represent the business entity participating in the revenue sharing. The node attributes include main entity number, main entity type, main entity role, main entity status, and main entity settlement priority.

[0043] Contract nodes are used to represent the contract documents or records on which the revenue sharing settlement depends. Node attributes include contract number, contract validity status, contract scope of application, and contract associated parties.

[0044] Rule nodes are used to represent rate rules, revenue sharing rules, deduction rules, and settlement cycle rules. Node attributes include rule number, rule type, rule status, applicable conditions, and rule priority.

[0045] Event nodes are used to represent refund after-sales events. Node attributes include event number, event type, event status, amount to be deducted, and direction of deduction.

[0046] Tax nodes are used to represent invoices and tax information. Node attributes include invoice number, tax rate type, tax amount, invoicing status, and tax matching status.

[0047] Account nodes are used to represent split settlement accounts. Node attributes include account number, account type, account status, clearing channel, and account availability status.

[0048] Relationship extraction is used to generate a heterogeneous set of relationships, where payment correspondence connects order nodes and payment nodes, transaction attribution connects order nodes and entity nodes, and revenue sharing collaboration connects the main merchant entity node and participating revenue sharing entity nodes.

[0049] Rule constraint relationships connect contract nodes and rule nodes; contract applicability relationships connect subject nodes and contract nodes; refund offset relationships connect event nodes and order nodes; tax matching relationships connect tax nodes and order nodes; and account binding relationships connect subject nodes and account nodes.

[0050] The fund transfer relationship connects the payment node, the main node, and the account node, and is used to indicate the flow of transaction funds from the completion of payment to the settlement of accounts.

[0051] The account clearing relationship connects account nodes and clearing status data, indicating whether the account can execute split accounting, whether it is frozen, and whether clearing is complete.

[0052] When constructing knowledge graph triples, each triple is stored in the form of a head node, a relation, and a tail node, and business role tags, funding direction tags, rule status tags, event status tags, and account settlement tags are added to the triples.

[0053] Business role tags are used to represent the identity of a node in a revenue-sharing scenario, including order initiator, payee, revenue sharer, rule provider, refund bearer, invoice issuer, and invoice recipient.

[0054] The fund direction label is used to indicate the flow of funds, including payment inflow, account outflow, refund reduction, account crediting, and settlement completion.

[0055] Rule status labels are used to indicate whether a contract rule is valid, expired, suspended, or manually locked.

[0056] Event status labels are used to indicate the processing status of refund, after-sales, cancellation, and reversal events.

[0057] Account liquidation labels are used to indicate whether an account is valid, reachable, frozen, successfully liquidated, or whether there has been a liquidation failure.

[0058] Graph cleaning is used to remove duplicate nodes, merge multiple system identifiers of the same entity, eliminate invalid account relationships, label conflicting relationships, and isolate isolated relationships.

[0059] Instead of directly deleting conflicting relationships, conflict markers are added to the graph, enabling the model to identify contract rule conflicts, refund reduction conflicts, tax account conflicts, and fund loop conflicts in subsequent processing.

[0060] In this embodiment, S3 specifically includes: constructing transaction entity identification path, contract constraint path, refund offset path, tax invoice path, account reachability path and fund closed-loop verification path based on the split settlement knowledge graph, extracting and filtering path instances to obtain a set of settlement meta-path instances.

[0061] The transaction entity identification path is used to connect the order node, merchant entity node, and revenue sharing participant node to determine the set of entities actually participating in revenue sharing for the current order.

[0062] The contract constraint path is used to connect the order node, the subject node, the contract node, and the rule node to determine the contract terms, rate rules, and revenue sharing boundaries applicable to the current order.

[0063] The refund reduction path is used to connect the order node, the refund after-sales event node, the refund responsible entity node, and the original payment node to determine the impact of the refund event on the revenue sharing ratio and the amount to be settled.

[0064] The tax invoice path is used to connect the order node, tax node, invoice issuer node, and invoice recipient node to determine whether the invoice tax rate, invoice status, and tax entity are consistent with the accounting results.

[0065] The account reachability path is used to connect the revenue sharing entity node, settlement account node, clearing channel node, and account status node to determine whether the candidate revenue sharing entity has an executable settlement account.

[0066] The fund closed-loop verification path is used to connect the payment node, order node, accounting entity node, settlement account node, and clearing status node to determine whether the payment, accounting, recording, and clearing processes form a complete closed loop.

[0067] After the candidate settlement meta-path set is generated, the system traverses the accounting settlement knowledge graph according to the path pattern to obtain the candidate settlement meta-path instance set.

[0068] The path instance filtering process includes node role integrity filtering, fund direction consistency filtering, rule applicability filtering, refund relevance filtering, tax account matching filtering, and account reachability filtering.

[0069] Node role integrity is used to determine whether the path contains the order node, subject node, rule node, and account node required for the current revenue sharing inference.

[0070] Consistency of fund direction is used to determine whether the direction of payment inflow, account outflow, refund reduction, and account crediting is consistent with the transaction sequence.

[0071] Rule applicability is used to determine whether contract rules match the order type, subject roles, and transaction status.

[0072] Refund relevance is used to determine whether a refund event corresponds to the current order or its original payment transaction, preventing irrelevant refunds from affecting the revenue sharing ratio.

[0073] Tax account matching is used to determine whether there is a corresponding relationship between the invoice holder, the invoice recipient, and the accounting entity.

[0074] Account accessibility is used to determine whether a settlement account is valid, not frozen, and can be credited through clearing channels.

[0075] Path contribution calculation is used to measure the connection contribution of different settlement meta-paths to the identification of the accounting entity, contract rule matching, refund reduction identification, tax account matching, account path confirmation, and fund closure verification.

[0076] The path contribution is set to a value between 0 and 1, where 0 indicates that the path has no valid contribution and 1 indicates that the path is a complete match with no conflicts.

[0077] When the integrity of node roles, consistency of funding direction, applicability of rules, relevance of refunds, matching of tax accounts, and accessibility of accounts are all satisfied, the path contribution is recorded as 1.

[0078] When there are missing nodes, broken relationships, conflicting directions, or unreachable accounts, the path contribution is reduced based on the number and type of abnormal items.

[0079] The set of settlement metapath instances not only serves as input to the model, but is also used to explain the revenue sharing ratio, account path, and sources of abnormal risks generated by the subsequent model.

[0080] In this embodiment, S4 specifically includes: inputting the revenue sharing and settlement knowledge graph and the settlement meta-path instance set into the improved knowledge graph heterogeneous graph attention network model, and performing fund direction constraint relationship gating, two-layer attention and settlement conflict perception fusion to obtain subject embedding representation, settlement relationship weight, path semantic weight and abnormal risk weight.

[0081] The improved knowledge graph heterogeneous graph attention network model includes a heterogeneous graph initial feature encoding layer, a funding direction constraint gating layer, a path-internal node-level attention layer, a path-inter-semantic level attention layer, and a settlement conflict perception fusion layer.

[0082] The initial feature encoding layer of the heterogeneous graph performs vector encoding on node attributes, relation attributes, and settlement semantic labels to obtain the initial feature representation of the heterogeneous graph.

[0083] Order nodes, payment nodes, entity nodes, contract rule nodes, refund event nodes, tax nodes, and account nodes are each encoded as vectors.

[0084] Relationship type, funding direction, rule status, event status, and account settlement status are each encoded as a relation context vector.

[0085] The funding direction constraint gating layer is used to solve the problem that ordinary heterogeneous graph attention models cannot distinguish between funding flow and constraint strength.

[0086] The relationship gating coefficient is generated based on the contextual features of the relationship. The generation process takes into account the relationship type, funding direction, contract status, refund status, tax status, and account status.

[0087] The relation gating coefficient ranges from 0 to 1 and is used to adjust the influence of different relations in the message passing process.

[0088] When the relationship is directly related to the current revenue sharing task and its state is valid, the relationship gating coefficient is close to 1.

[0089] When a relation is irrelevant to the current order, is in an invalid state, or has a conflicting direction, the relation gating coefficient is close to 0.

[0090] During message passing, the system first adjusts the information strength of neighbor nodes transmitted to the current node based on the relationship gating coefficient, and then uses the adjusted neighbor information for subsequent attention calculation.

[0091] Fund transfer relationships have a high threshold coefficient when the payment status is completed and the account is available.

[0092] Contractual constraints have a high gating coefficient when the contract is valid and the rules apply.

[0093] The refund reduction relationship has a high gating coefficient when the refund is completed and associated with the current order.

[0094] The tax relationship of invoices has a high threshold coefficient when matching the invoicing entity and the accounting entity.

[0095] Account clearing relationships have a high threshold coefficient when the account is valid and clearing channels are available.

[0096] Through relational gating, the model is able to suppress noise from invalid contracts, irrelevant refunds, invalid accounts, and conflicting tax relationships during the graph messaging phase.

[0097] The node-level attention layer within the path is used to calculate the degree of influence of different nodes within the same settlement element path on the current order's revenue sharing result.

[0098] The system takes the current order node as the central node, extracts the set of neighboring nodes under each type of settlement metapath, and calculates the attention score of nodes in the path based on the characteristics of the order node, the characteristics of neighboring nodes, and the relationship gating characteristics.

[0099] The attention score of nodes within the path is used to represent the degree of contribution of neighboring nodes to the identification of the revenue sharing entity, the generation of revenue sharing ratio, or the matching of accounts for the current order.

[0100] After the attention scores of nodes within the path are normalized, the importance of each neighboring node within the same path is converted into comparable node contribution weights.

[0101] In the contract constraint path, contract nodes and rule nodes have a significant impact on the revenue sharing ratio boundary.

[0102] In the refund reduction path, the refund event node and the node of the entity responsible for the refund have a significant impact on the adjustment of the revenue share.

[0103] In the account reachability path, the settlement account node and the clearing channel node have a significant impact on the generation of the funds path.

[0104] After the node-level attention calculation within the path is completed, the system performs weighted aggregation on neighboring nodes within the same path to obtain the aggregated representation of the nodes within the path.

[0105] The node aggregation representation within the path is formed by the characteristics of each neighboring node and the contribution weight of the corresponding node, and is used to represent the local settlement information related to the order under the current settlement metapath.

[0106] Node contribution weight is used to record the degree of contribution of each node to the current order revenue sharing inference.

[0107] The semantic-level attention layer between paths is used to calculate the overall impact of different settlement meta-paths on revenue sharing ratio generation, fund path generation, and abnormal risk identification.

[0108] The system constructs a proportional query vector, an account query vector, and a risk query vector based on the set of multi-path settlement representations.

[0109] The proportional query vector is used to focus on the impact of contract constraint paths, transaction entity identification paths, and refund reduction paths on the revenue sharing ratio.

[0110] Account query vectors are used to monitor the impact of account reachability paths and fund closed-loop verification paths on settlement paths.

[0111] Risk query vectors are used to monitor the impact of refund reduction paths, tax invoice paths, and fund closed-loop verification paths on abnormal risks.

[0112] The system calculates the semantic relevance between each settlement element path and the proportional query vector, account query vector, and risk query vector.

[0113] The semantic relevance is normalized to form the path semantic weight.

[0114] Path semantic weights include proportional semantic weights, account semantic weights, and risk semantic weights.

[0115] Proportional semantic weights are used to describe the degree of influence of each settlement metapath on the generation of revenue sharing ratios.

[0116] Account semantic weights are used to describe the degree of influence of each settlement metapath on the generation of funding paths.

[0117] Risk semantic weights are used to describe the degree of influence of each settlement metapath on the identification of abnormal risks.

[0118] By using path semantic weights, the model can determine whether the current order relies more on contract rules, refund reductions, tax invoices, account accessibility, or a closed-loop fund relationship for revenue sharing inference.

[0119] The settlement conflict perception fusion layer is used to identify conflict relationships between graph paths and transform these conflict relationships into abnormal risk weights.

[0120] The system generates an order-level settlement fusion representation based on node contribution weights and path semantic weights.

[0121] The order-level settlement fusion is represented by a weighted fusion of the nodes within the paths corresponding to the transaction entity identification path, contract constraint path, refund offset path, tax invoice path, account reachability path, and fund closed-loop verification path.

[0122] The system extracts subject features, rule features, event features, tax features, account features, and closed-loop features from the order-level settlement fusion representation to form a set of settlement conflict identification features.

[0123] The intensity of rule conflict is used to indicate whether there is a contradiction between the contractual constraint path and the rule application relationship.

[0124] Event conflict intensity is used to indicate whether there is a discrepancy between the refund reduction path and the original transaction entity identification path regarding the reduction object.

[0125] Tax conflict intensity is used to indicate whether there is a mismatch between the invoicing entity or tax rate between the tax invoice path and the semantic representation of the revenue sharing ratio.

[0126] Account conflict intensity is used to indicate whether there is an account that is unreachable, frozen, or has failed to be settled between the account reachable path and the fund closed-loop verification path.

[0127] The system generates risk gating vectors based on the intensity of rule conflicts, event conflicts, tax conflicts, and account conflicts.

[0128] Risk gating vectors are used to weight and suppress the subject dimension, rule dimension, event dimension, tax dimension, and account dimension in the order-level settlement fusion representation.

[0129] When a certain dimension corresponds to a high level of conflict, the effective contribution of that dimension to the risk perception settlement representation is reduced.

[0130] When a certain dimension is free from conflict and strongly correlated with the current order, its effective contribution to the risk perception settlement representation is retained.

[0131] After processing by the output layer, the risk-aware settlement representation generates the subject embedding representation, settlement relationship weights, and abnormal risk weights.

[0132] Subject embedding is used to describe the settlement role and association strength of the revenue sharing subject in the current order.

[0133] Settlement relationship weights are used to describe the strength of the effective relationship between orders, entities, contracts, refunds, taxes, and accounts.

[0134] Path semantic weights are used to describe the degree of impact of each settlement metapath on proportions, accounts, and risk tasks.

[0135] Anomaly risk weights are used to describe the likelihood of anomalies in the current order in terms of payment amount, contract rules, refund reduction, tax account, and fund closure.

[0136] In this embodiment, S5 specifically includes: decoding the revenue sharing ratio, verifying account accessibility, and jointly sorting the ratio path based on the subject embedding representation, settlement relationship weight, path semantic weight, abnormal risk weight, and contract rules, to obtain the intelligent revenue sharing ratio, revenue sharing settlement path, and account mapping results.

[0137] The system first determines the set of candidate revenue sharing entities based on the entity embedding representation and settlement relationship weight.

[0138] Each entity in the candidate revenue sharing entity set has a corresponding entity role, rule association, account binding, and settlement status.

[0139] The system constructs a subject proportion score based on candidate revenue sharing object data, subject embedding representation, settlement relationship weight, and path semantic weight.

[0140] The subject proportion score is used to represent the relative strength of the candidate subject's share of revenue in the current order.

[0141] The subject proportion score is formed by the contribution of transaction subject identification, contractual constraint, refund reduction, tax matching, and account accessibility.

[0142] For candidate revenue sharing entities, the system generates entity proportion scores based on the entity's embedded representation, settlement relationship weight, proportion semantic weight, and contract rule features.

[0143] The system normalizes the main entity's proportion score to obtain the initial revenue sharing ratio.

[0144] Normalization ensures that the sum of the initial revenue sharing ratios of each candidate revenue sharing entity corresponds to the revenue sharing amount of the current order.

[0145] The proportionality conservation constraint is used to ensure that the sum of the revenue sharing amounts corresponding to each candidate entity does not exceed the distributable revenue sharing amount.

[0146] Contractual constraints are used to ensure that the revenue sharing ratio does not exceed the upper and lower limits specified in the contract rules.

[0147] Refund reduction constraints are used to reduce the distributable amount based on the refund amount, refund status, and the entity responsible for the refund.

[0148] Tax matching constraints are used to ensure that there are no inconsistencies between the accounting entity, the invoicing entity, and tax rules.

[0149] The system modifies the initial revenue sharing ratio based on the proportionality conservation constraint, contract application constraint, refund offset constraint, and tax matching constraint, thus obtaining a set of candidate revenue sharing ratios.

[0150] When the candidate ratio exceeds the contract limit, the system will reallocate the excess portion to entities that meet the contractual constraints and are accessible to the account.

[0151] When a refund event is undertaken by a certain entity, the system reduces the corresponding distributable amount or distributable ratio of that entity according to the refund reduction path.

[0152] When the tax matching status is abnormal, the system marks the candidate proportion of the subject corresponding to the tax abnormality as pending verification and participates in the subsequent abnormal risk ranking.

[0153] The system verifies account reachability based on the candidate revenue sharing ratio set, settlement account data, and account reachability path.

[0154] Account accessibility verification includes account validity verification, account freeze status verification, clearing channel availability verification, and account entity matching verification.

[0155] Account validity verification is used to determine whether a settlement account is in a state where funds can be credited.

[0156] Account freeze status verification is used to determine whether an account has been locked, frozen, or suspended.

[0157] The clearing channel availability check is used to determine whether the payment channel and the settlement account can complete the fund clearing.

[0158] Account entity matching verification is used to determine whether the settlement account is bound to the candidate split account.

[0159] After passing the account accessibility verification, the system generates a set of candidate revenue sharing and settlement paths.

[0160] The candidate revenue sharing and settlement path set represents the executable path for funds to start from the account corresponding to the payment flow, pass through the revenue sharing entity and the clearing channel, and enter the settlement account.

[0161] The system constructs proportional penalty items, path blocking items, and rule correction items based on the abnormal risk weights.

[0162] The proportional penalty item is used to reduce the candidate revenue sharing ratio score for entities with higher abnormal risk.

[0163] The path blocking option is used to block candidate paths for accounts that are unreachable, frozen, or have failed to be liquidated.

[0164] The rule correction item is used to correct the impact of contract rule conflicts, refund reduction conflicts, and tax account conflicts on candidate ratios and paths.

[0165] The system constructs a joint scoring matrix for proportional paths based on the set of candidate revenue sharing ratios, the set of candidate revenue sharing settlement paths, proportional penalty items, path blocking items, and rule correction items.

[0166] The rows of the proportional path joint scoring matrix correspond to the candidate revenue sharing entities and their candidate revenue sharing ratios, while the columns correspond to the candidate settlement accounts and funding paths.

[0167] Each element in the proportional path joint scoring matrix represents the comprehensive executable score when a candidate revenue sharing entity adopts the corresponding candidate revenue sharing ratio and matches a candidate funding path.

[0168] The overall executable score is determined by the entity proportion score, account accessibility score, abnormal risk suppression score, rule application score, and fund closure score.

[0169] Account reachability score is generated based on account validity status, account freeze status, clearing channel availability status, and account entity matching status.

[0170] The abnormal risk suppression score is generated based on the abnormal risk weight. The higher the abnormal risk weight, the lower the executable score of the corresponding combination.

[0171] The rule application score is generated based on contract application constraints, refund offset constraints, and tax matching constraints.

[0172] The closed-loop funding score is generated based on the path integrity between payment nodes, revenue sharing nodes, account nodes, and settlement status nodes.

[0173] The system performs joint scoring, conflict suppression, and accessibility ranking based on the proportional path joint scoring matrix.

[0174] Joint scoring is used to simultaneously select the revenue sharing ratio and funding path, avoiding mismatches between the ratio and path caused by determining the ratio first and then selecting the account.

[0175] Conflict suppression is used to reduce the combined score of rule conflicts, refund conflicts, tax conflicts, or account conflicts.

[0176] Reachability ranking prioritizes path combinations that prioritize account status, availability of clearing channels, and complete fund closure.

[0177] After sorting, the system obtains the intelligent revenue sharing ratio, revenue sharing settlement path, and account mapping results.

[0178] The intelligent revenue sharing ratio represents the revenue sharing share corresponding to each candidate revenue sharing entity in the current order.

[0179] The separate settlement path indicates the path of funds from the payment flow to the separate account holder and then to the account clearing.

[0180] The account mapping results represent the target settlement account, clearing channel, and fund receipt status corresponding to each sub-account entity.

[0181] In this embodiment, S6 specifically includes: generating a settlement result based on the intelligent revenue sharing ratio, revenue sharing settlement path and account mapping result, and verifying and attributing the result by combining payment flow, contract rules, refund after-sales service, invoice taxation, account clearing and abnormal risk weight, so as to obtain the settlement verification result and abnormal settlement prompt result.

[0182] The system generates order-level revenue sharing details based on the intelligent revenue sharing ratio, revenue sharing settlement path, and account mapping results.

[0183] The detailed breakdown of revenue sharing includes the order number, the entity sharing the revenue, the revenue sharing ratio, the revenue sharing amount, the settlement account, the clearing channel, the settlement status, and the abnormality indicator.

[0184] Payment consistency verification is used to determine whether the order payment amount, refund amount, distributable amount, and distributable amount of each entity are consistent.

[0185] The rule consistency check is used to determine whether the revenue sharing ratio, revenue sharing entity, and settlement cycle comply with the contract rules and fee rate rules.

[0186] Tax account consistency verification is used to determine whether there is consistency between the accounting entity, the invoicing entity, the invoice receiving entity, tax rate information, and account settlement information.

[0187] The fund loop consistency check is used to determine whether a closed loop is formed between payment completion, account splitting, account posting, and settlement completion.

[0188] The system performs joint analysis on the payment consistency verification results, rule consistency verification results, tax account verification results, and abnormal risk weights to determine the source of the anomaly.

[0189] When the payment amount is inconsistent with the revenue sharing amount, the source of the anomaly is marked as a payment amount conflict.

[0190] When the contract rules and revenue sharing ratios are inconsistent, the source of the anomaly is marked as a contract rule conflict.

[0191] When the refund event and the revenue sharing amount are inconsistent, the source of the anomaly is marked as a refund offset conflict.

[0192] When the tax information on the invoice is inconsistent with the accounting entity or the accounting amount, the source of the discrepancy is marked as a tax account conflict.

[0193] When there are unreachable accounts, failed settlements, or missing crediting statuses in the fund transfer path, the abnormal source is marked as a fund loop conflict.

[0194] The abnormal settlement notification results include the abnormal order number, abnormal subject, abnormal path, abnormal type, risk weight, and suggested review object.

[0195] The abnormal settlement notification result is provided to settlement personnel, financial systems, or risk control systems for further review and processing.

[0196] To verify the feasibility of this invention in practice, it was applied to a transaction settlement scenario involving multi-entity accounting, refund reversal, and tax account verification.

[0197] In this scenario, the basic dataset contains 18,000 order records, 18,420 payment transaction records, 1,260 revenue sharing entity records, 438 contract rule records, 1,320 refund and after-sales records, 9,760 invoice and tax records, and 1,488 settlement account records.

[0198] After the system completes field standardization and subject alignment, it forms 18,000 order nodes, 18,420 payment nodes, 1,260 subject nodes, 438 contract rule nodes, 1,320 event nodes, 9,760 tax nodes, and 1,488 account nodes.

[0199] The knowledge graph for split-payment settlement has formed 50,706 heterogeneous nodes and 142,600 heterogeneous relationships.

[0200] The system extracted approximately 286,000 settlement meta-path instances from the revenue sharing and settlement knowledge graph. After filtering based on node role completeness, fund direction consistency, rule applicability, refund relevance, tax account matching, and account accessibility, approximately 213,000 valid settlement meta-path instances were retained.

[0201] After the improved knowledge graph heterogeneous graph attention network model outputs the subject embedding representation, settlement relationship weight, path semantic weight, and abnormal risk weight, the system generates approximately 45,200 sets of candidate revenue sharing ratios and approximately 38,900 sets of candidate revenue sharing settlement paths.

[0202] After sorting by the proportional path joint scoring matrix, the system generates settlement results for 18,000 orders, of which 16,984 orders were settled normally and 1,016 orders were flagged as having anomalies.

[0203] Among the orders with abnormal notifications, there were 148 orders with payment amount conflicts, 276 orders with contract rule conflicts, 231 orders with refund reduction conflicts, 189 orders with tax account conflicts, and 172 orders with fund closure conflicts.

[0204] The manual review results showed that 937 of the orders with abnormality alerts were confirmed to be settlement abnormalities that required adjustment or review, with an accuracy rate of approximately 92.2%.

[0205] Under the same data range, the fixed-rule revenue sharing method requires manual review of approximately 3,260 orders. This invention reduces the number of orders to be manually reviewed to 1,016, a reduction of approximately 68.8%.

[0206] Account unreachability anomalies generated using fixed-rule revenue sharing methods need to be manually discovered after settlement. This invention identifies 172 unreachable paths in advance during the result generation stage by using a joint scoring matrix of account reachable paths and proportional paths.

[0207] Through the above processing, the present invention can start from the original transaction data and sequentially complete graph modeling, path extraction, model reasoning, ratio decoding, path sorting, result verification and anomaly attribution, and finally obtain an executable, verifiable and traceable intelligent accounting and settlement result.

[0208] Compared to a fixed-ratio settlement method, this invention uses subject embedding representation, settlement relationship weight, path semantic weight, and abnormal risk weight to jointly participate in ratio decoding, enabling the revenue sharing ratio to be dynamically adjusted according to contract rules, refund events, tax status, and account status.

[0209] Compared to simple knowledge graph query methods, this invention uses an improved knowledge graph heterogeneous graph attention network model to calculate the contribution weights of different relationships and paths, transforming graph relationships from static query results into model features that can participate in revenue sharing decoding.

[0210] Compared to ordinary heterogeneous graph attention networks, this invention adds fund direction constraint relationship gating in the relationship message passing stage, adds proportion, account and risk query vectors in the path semantic calculation stage, adds risk gating vector in the fusion stage, and adds proportion path joint scoring matrix in the revenue generation stage.

[0211] The basic dataset, the revenue sharing and settlement knowledge graph, the settlement meta-path instance set, the subject embedding representation, the settlement relationship weight, the path semantic weight, the abnormal risk weight, the proportional path joint scoring matrix, and the settlement verification results in this invention form a complete data processing closed loop.

[0212] Example 1: To verify the feasibility of this invention in practice, it was applied to a multi-entity order revenue sharing and settlement scenario on a comprehensive transaction service platform. In this scenario, the platform simultaneously accesses online orders, offline verification orders, aggregated payment records, merchant contract rules, service performance records, refund and after-sales records, invoice tax records, and settlement account information. After each transaction is completed, the transaction amount needs to be shared among the platform, participating merchants, performance service providers, promotion service providers, and payment channels. Furthermore, the contract rates, service roles, refund reduction rules, and account settlement status differ among these different entities. Traditional rule templates can perform calculations when handling single merchants, single contracts, and fixed-rate orders. However, when the same order is simultaneously associated with subsidies, partial refunds, cross-account settlements, and invoice tax rate changes, problems such as missed identification of revenue sharing entities, inconsistencies between revenue sharing ratios and contract terms, unreachable settlement accounts, and difficulties in locating abnormal sources can easily arise.

[0213] In this embodiment, basic settlement data is first extracted from the order system, payment system, contract management system, after-sales system, tax system, and account system. Order numbers, payment transaction numbers, entity identifiers, contract numbers, rate rule numbers, refund order numbers, invoice identifiers, and account identifiers are standardized and then chronologically organized according to the business sequence of order creation, payment completion, after-sales triggering, invoice generation, and account clearing. After processing, the following data is obtained: 128,600 order samples, 132,480 payment transaction records, 936 settlement entities, 418 contract rules, 18,420 refund and after-sales events, 96,500 invoice and tax records, and 1,028 settlement accounts.

[0214] Subsequently, orders, payments, entities, contracts, rules, events, taxes, and accounts are constructed as heterogeneous nodes, and transaction attribution, fund flow, contractual constraints, rule applicability, refund reversal, invoice taxation, and account settlement are constructed as heterogeneous relationships, forming a separate settlement knowledge graph. To enable the graph to serve separate settlement reasoning, this embodiment further constructs transaction entity identification paths, contractual constraint paths, refund reversal paths, tax invoice paths, account reachability paths, and fund closure verification paths. The completeness of node roles, consistency of fund direction, applicability of contract rules, relevance of refund reversal, tax account matching, and account reachability in the path instances are then filtered to obtain a set of settlement meta-path instances that can be input into the model.

[0215] In the model processing stage, the revenue sharing and settlement knowledge graph and the set of settlement meta-path instances are input into the improved knowledge graph heterogeneous graph attention network model. The model first performs vector encoding on node attributes, relationship attributes, fund direction labels, rule state labels, event state labels, and account settlement labels. Then, it adjusts the message transmission intensity of different relationships through fund direction constraint gating, giving fund flow relationships, contract constraint relationships, refund offset relationships, invoice and tax relationships, and account settlement relationships different influence weights in different order scenarios. Within each path, the model performs node-level attention computation to obtain the contribution weights of the revenue sharing entity, contract rules, refund events, tax invoices, and settlement accounts to the current order. Then, it performs semantic-level attention computation between paths to obtain the influence weights of different settlement meta-paths on the revenue sharing ratio, settlement account, and abnormal risk.

[0216] For orders with conflicting rules, the model further performs settlement conflict perception fusion. It generates risk gating vectors based on conflicts between contractual constraint paths and rule applicability relationships, refund reduction paths and original transaction entity identification paths, tax invoice paths and revenue sharing ratio semantic representations, and account reachability paths and fund closure verification paths. These risk gating vectors weight and suppress the subject, rule, event, tax, and account dimensions in the order-level settlement fusion representation to obtain a risk-aware settlement representation. The model then outputs the subject embedding representation, settlement relationship weights, and abnormal risk weights.

[0217] In the revenue sharing result generation stage, the system determines the candidate revenue sharing entity set based on the entity embedding representation and settlement relationship weights, and then constructs the entity proportion score by combining path semantic weights and contract rules. The system processes the entity proportion score with proportion conservation constraints, contract application constraints, refund reduction constraints, and tax matching constraints to obtain the candidate revenue sharing proportion set; subsequently, it performs account reachability verification by combining settlement account data and account reachability paths to obtain the candidate revenue sharing settlement path set. The system constructs proportion penalty items, path blocking items, and rule correction items based on abnormal risk weights, and forms a proportion-path joint scoring matrix. Through joint scoring, conflict suppression, and reachability ranking, the final intelligent revenue sharing proportion, revenue sharing settlement path, and account mapping results are obtained.

[0218] To verify the effectiveness of this invention, the method of this invention was compared with a fixed rule template-based revenue sharing method and a revenue sharing method that only uses knowledge graph relationship queries. During the comparison, the revenue sharing entity, revenue sharing ratio, settlement path, and anomaly type after manual review and confirmation were used as reference results. Under the same order sample, the same contract rules, and the same refund and after-sales data, the accuracy rate of entity identification, the average error of the ratio, the accuracy rate of settlement path matching, the anomaly identification recall rate, the proportion of manual review, the average processing time, and the pass rate of fund closure verification were statistically analyzed.

[0219] Table 1 Comparison of the implementation effects of different revenue-sharing settlement methods

[0220] Table Analysis As shown in Table 1, in terms of the accuracy of revenue sharing entity identification, the fixed rule template revenue sharing method is limited by the preset rules and is prone to omissions when facing changes in entity roles and multi-entity collaborative orders. The method of this invention expresses the heterogeneous relationship between orders, entities, contracts, refunds and accounts through a revenue sharing settlement knowledge graph, and uses in-path node-level attention to identify key neighbor nodes, so that the accuracy of revenue sharing entity identification reaches 98.73%.

[0221] Regarding the average error of the revenue sharing ratio, fixed-rule template revenue sharing methods mainly rely on static rates, making it difficult to simultaneously handle constraints such as contract application, refund reversal, and tax matching. Knowledge graph relationship query methods can enhance relationship matching capabilities, but lack the ability to learn the degree of influence of different paths. The method of this invention obtains the influence weights of different settlement meta-paths on the ratio generation through semantic attention between paths, and decodes them through ratio conservation constraints, contract application constraints, refund reversal constraints, and tax matching constraints, thereby reducing the average error of the ratio to 0.52%.

[0222] Regarding the accuracy of settlement path matching and the pass rate of fund loop verification, the method of this invention introduces account reachability paths and fund loop verification paths, and simultaneously considers the revenue sharing ratio, account path, abnormal risk, and reachability ranking in the proportional path joint scoring matrix, so that the settlement ratio, fund flow path, and account mapping results are determined synchronously. Therefore, this invention can reduce the problem of correct revenue sharing ratios but unexecutable account paths, achieving a settlement path matching accuracy of 98.21% and a fund loop verification pass rate of 99.05%.

[0223] Regarding anomaly identification recall, the method of this invention integrates settlement conflict perception to calculate the intensity of rule conflicts, event conflicts, tax conflicts, and account conflicts, and generates a risk gating vector based on the intensity of multi-source settlement conflicts. This enables the model to identify anomaly risks in advance during the generation stages of revenue sharing ratios and settlement paths. Compared to traditional methods that require manual checks after revenue sharing is completed, this invention can generate anomaly risk weights during the generation stage and attribute anomalies by combining payment, rule, tax, and account verification results during the final verification stage.

[0224] In terms of processing efficiency, the method of this invention integrates multi-source data standardization, graph relationship reasoning, attention weight calculation, proportional path joint sorting, and consistency verification into a continuous processing flow, reducing the proportion of manual review to 4.28% and the average processing time per batch to 18.6 minutes. These results demonstrate that this invention not only improves the automated processing capabilities under complex accounting and settlement relationships but also enhances the stability of abnormal settlement location and settlement closed-loop verification.

[0225] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A knowledge graph-based intelligent revenue sharing and settlement method, characterized in that, Includes the following steps: S1. Obtain transaction orders, payment records, accounting entities, contract rules, refund and after-sales service, invoice tax and settlement account data, and perform field standardization, entity alignment and time series organization to obtain the basic dataset; S2. Extract order, payment, entity, contract, rule, event, tax and account nodes from the basic dataset, and construct a split settlement knowledge graph based on transaction ownership, fund flow, contract constraints, rule application, refund reduction, invoice tax and account settlement relationships; S3. Based on the accounting and settlement knowledge graph, construct the transaction entity identification path, contract constraint path, refund offset path, tax invoice path, account reachability path, and fund closed-loop verification path, extract and filter path instances to obtain a set of settlement meta-path instances; S4. Input the knowledge graph of revenue sharing and settlement and the set of settlement meta-path instances into the improved knowledge graph heterogeneous graph attention network model, and perform fusion of fund direction constraint relationship gating, two-layer attention and settlement conflict perception to obtain subject embedding representation, settlement relationship weight, path semantic weight and abnormal risk weight. S5. Based on the subject embedding representation, settlement relationship weight, path semantic weight, abnormal risk weight and contract rules, perform revenue sharing ratio decoding, account accessibility verification and joint sorting of ratio paths to obtain intelligent revenue sharing ratio, revenue sharing settlement path and account mapping results. S6. Generate settlement results based on the intelligent revenue sharing ratio, revenue sharing settlement path and account mapping results, and verify and attribute them in conjunction with payment flow, contract rules, refund and after-sales service, invoice taxation, account clearing and abnormal risk weights to obtain settlement verification results and abnormal settlement prompt results.

2. The intelligent revenue sharing and settlement method based on knowledge graphs according to claim 1, characterized in that, S2 includes the following steps: S21. Extract order, payment, entity, contract, rule, event, tax and account objects from the basic dataset to obtain a heterogeneous node set; S22. Extract relationships based on payment correspondence, transaction ownership, revenue sharing, rule constraints, refund offsetting, tax matching, and account binding to obtain a heterogeneous set of relationships; S23. Construct knowledge graph triples based on the heterogeneous node set and heterogeneous relationship set, and add business roles, funding directions, rule status, event status and account settlement tags to obtain graph relationship data; S24. Construct a revenue-sharing settlement knowledge graph based on the graph relationship data, and clean up duplicate nodes, conflicting relationships, isolated relationships and invalid account relationships to obtain the revenue-sharing settlement knowledge graph.

3. The intelligent revenue sharing and settlement method based on knowledge graphs according to claim 1, characterized in that, S3 includes the following steps: S31. Construct the six types of settlement meta-paths as described in claim 1 based on the node types and relationship types in the split settlement knowledge graph to obtain a set of candidate settlement meta-paths; S32. Traverse the accounting and settlement knowledge graph based on the candidate settlement meta-path set to obtain the candidate settlement meta-path instance set; S33. Filter based on node role completeness, fund direction consistency, rule applicability, refund relevance, tax account matching, and account reachability to obtain a set of valid settlement metapath instances; S34. Calculate the connection contribution of each path based on the set of valid settlement metapath instances to obtain the set of settlement metapath instances.

4. The intelligent revenue sharing and settlement method based on knowledge graphs according to claim 1, characterized in that, S4 includes the following steps: S41. Vector encode the node attributes, relation attributes, and settlement semantic labels in the revenue sharing and settlement knowledge graph to obtain the initial feature representation of the heterogeneous graph; S42. Based on the initial feature representation of the heterogeneous graph and the set of settlement element path instances, perform fund direction constraint relationship gating processing to obtain relationship gating features; S43. Calculate node-level attention within the path based on relational gating features to obtain node contribution weights; S44. Perform semantic-level attention calculation between paths based on the node contribution weights to obtain the path semantic weights; S45. Based on the node contribution weight and path semantic weight, perform settlement conflict perception fusion to obtain the subject embedding representation, settlement relationship weight and abnormal risk weight.

5. The intelligent revenue sharing and settlement method based on knowledge graphs according to claim 4, characterized in that, S42 includes the following steps: S421. Extract relationship type, funding direction, contract, refund, tax and account features based on the initial feature representation of the heterogeneous graph to obtain the settlement relationship context feature set; S422. Generate relation gating coefficients based on the settlement relation context feature set; S423. Adjust the message transmission strength of fund, contract, refund, tax and account relationships according to the relationship gating coefficient to obtain the relationship adjustment message characteristics; S424. Based on the relationship adjustment message characteristics, perform neighborhood information transmission and path aggregation to obtain the relationship gating characteristics.

6. The intelligent revenue sharing and settlement method based on knowledge graphs according to claim 4, characterized in that, S43 includes the following steps: S431. Determine the set of neighbor nodes of the current order node under different settlement meta paths based on the relation gating features, and obtain the path neighbor candidate set; S432. Perform attention matching based on the path neighbor candidate set, relationship gating features, and current order node features to obtain the attention score of nodes within the path; S433. Based on the attention scores of nodes within the path, the target neighbor nodes are weighted and aggregated to obtain the aggregated representation of nodes within the path. S434. Determine the contribution level of neighboring nodes based on the node aggregation representation within the path, and obtain the node contribution weight.

7. The intelligent revenue sharing and settlement method based on knowledge graphs according to claim 4, characterized in that, S44 includes the following steps: S441. Aggregate the path representations of each settlement element path according to the node contribution weight to obtain a multi-path settlement representation set; S442. Construct proportion, account, and risk query vectors based on the multi-path settlement representation set, and calculate semantic relevance to obtain multi-task semantic attention scores; S443. Weighted fusion is performed based on the multi-task semantic attention scores to obtain semantic representations of proportion, account, and risk. S444. Determine the degree of influence of each path based on the proportion, account, and risk semantic representation to obtain the path semantic weight.

8. The intelligent revenue sharing and settlement method based on knowledge graphs according to claim 4, characterized in that, S45 includes the following steps: S451. Generate an order-level settlement fusion representation based on node contribution weight and path semantic weight, and extract subject, rule, event, tax, account and closed-loop features to obtain a settlement conflict identification feature set; S452. Based on the settlement conflict identification feature set, calculate the rules, events, tax and account conflict intensity to obtain the multi-source settlement conflict intensity set; S453. Generate a risk gating vector based on the set of multi-source settlement conflict intensity, and perform dimensional weighted suppression on the order-level settlement fusion representation to obtain the risk-aware settlement representation; S454. Generate subject embedding representation, settlement relationship weight and abnormal risk weight based on risk perception settlement representation.

9. The intelligent revenue sharing and settlement method based on knowledge graphs according to claim 1, characterized in that, S5 includes the following steps: S51. Determine the candidate revenue sharing subject set based on the subject embedding representation and settlement relationship weight, and extract subject roles, rule associations, account bindings and settlement status to obtain candidate revenue sharing object data; S52. Construct the main body ratio score based on the candidate revenue sharing object data, settlement relationship weight and path semantic weight, and perform ratio, contract, refund and tax constraint processing to obtain the candidate revenue sharing ratio set; S53. Verify the candidate revenue sharing ratio set, settlement account data and account reachable path to obtain the candidate revenue sharing settlement path set; S54. Construct proportional penalty items, path blocking items, and rule correction items based on abnormal risk weights, and construct a proportional path joint scoring matrix; S55. Perform joint scoring, conflict suppression, and reachability sorting based on the proportional path joint scoring matrix to obtain the intelligent revenue sharing ratio, revenue sharing settlement path, and account mapping results.

10. The intelligent revenue sharing and settlement method based on knowledge graphs according to claim 1, characterized in that, S6 includes the following steps: S61. Generate a detailed breakdown of the revenue sharing based on the intelligent revenue sharing ratio, revenue sharing settlement path, and account mapping results, and obtain the settlement results; S62. Perform a consistency check between the settlement result and the payment transaction data to obtain the payment consistency check result; S63. Perform rule verification based on the settlement results, contract rule data, and refund and after-sales data to obtain the rule consistency verification result; S64. Based on the settlement results, invoice tax data, account clearing data, and fund closed-loop verification path, perform account consistency verification to obtain the tax account verification result; S65. Based on the abnormal risk weight and each verification result, perform abnormal attribution to obtain the settlement verification result and abnormal settlement prompt result.

Images