A rule engine-based financial shared billing intelligent approval method

Abstract

This invention discloses a rule engine-based intelligent approval method for financial shared expense reimbursement, specifically in the field of intelligent expense reimbursement approval. It addresses the challenges of unifying the handling of differences and conflicts in approval rules among participating parties in multi-party collaborative expense reimbursement scenarios, as well as the lack of risk identification capabilities in the approval process. The method identifies the business activity type of collaborative expense reimbursement requests, constructs a collaborative rule knowledge graph based on each participant's local rule engine, performs conflict detection and resolution on expense approval rule units, forming a conflict-free joint execution rule set, and generates sub-approval tasks with globally unified event identifiers. After completing local compliance verification for each participant, it further constructs cross-party execution trajectories based on the approval results and rule trigger sequences, identifies risks in the collaborative expense reimbursement execution mode, and generates a final approval decision result with risk warnings, achieving unified coordination and risk perception in complex collaborative expense reimbursement processes.

Description

Technical Field

[0001] This invention relates to the field of intelligent expense reimbursement approval technology, and more specifically, to a financial shared expense reimbursement intelligent approval method based on a rule engine. Background Technology

[0002] As corporate group operations and cross-organizational collaboration models continue to deepen, financial shared service centers are gradually becoming the core hub for expense reimbursement and approval among multiple enterprises and entities. In actual business scenarios, a single expense reimbursement transaction often involves multiple parties sharing the cost, such as joint marketing activities, cross-enterprise project collaboration, joint travel, or outsourcing service settlements. In such collaborative reimbursement scenarios, there are generally differences among the participating parties regarding expense attribution, sharing ratios, invoice compliance requirements, and approval authority settings.

[0003] Existing shared expense reimbursement systems are typically designed around approval rules for a single entity, making it difficult to effectively handle conflicts arising from the coexistence of rules from multiple parties. Common practices rely on manual communication or post-event adjustments, which not only increases the approval cycle but also easily introduces compliance risks. Furthermore, in complex collaborative reimbursement processes, even if the approval results of each participant formally meet the established rules, potential risks may still emerge in the execution path, rule triggering order, or failure mode. Existing systems often only focus on whether approval is granted, lacking the ability to conduct structured analysis and risk identification of the approval process itself, making it difficult to promptly detect business risk vulnerabilities hidden behind the consistent execution of rules.

[0004] Therefore, there is a need for an intelligent approval method for multi-party collaborative reimbursement scenarios. This method should be based on unified coordination of the rules executed by all participants, to structurally characterize the collaborative approval process, and to identify abnormal execution patterns, thereby improving the controllability and reliability of financial shared reimbursement in complex collaborative scenarios. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a rule engine-based intelligent approval method for financial shared expense reimbursement to address the problems raised in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A rule-based intelligent approval method for financial shared expense reimbursement includes the following steps: S1. Receive a collaborative expense reimbursement request event containing multi-party participation identifiers and expense details, and extract the type code of the expense reimbursement business activity; S2. Based on the type code and the identifier of each participant, retrieve the fee approval rule unit in predicate logic form from the collaborative rule knowledge graph built on the local rule engine of each participant; S3. Input the fee approval rule units of each participant into the conflict detection process based on forward chain reasoning, resolve the logical conflicts between the fee approval rule units in the conflict detection results, and output a set of conflict-free joint execution rules. S4. Based on the joint execution rule set, decouple and reorganize the cost and invoice information of the collaborative reimbursement request to generate sub-approval tasks that correspond to each participant and are accompanied by a globally unified event identifier. S5. Distribute the sub-approval tasks to the local rule engines of each participant for compliance verification, bind the approval results and rule trigger sequences in the approval process with the globally unified event identifier, and then return. S6. Based on the globally unified event identifier, extract the approval results and rule trigger sequences to perform cross-entity execution trajectories. Perform structured analysis on the rule trigger sequence offset, repeated trigger distribution and failure node position in the cross-entity execution trajectory of the failed sub-approval task approval results to form a trajectory feature set of the failed execution trajectory and establish a risk identification model for the collaborative reimbursement execution mode. S7. Identify the risks of the collaborative reimbursement execution mode corresponding to the currently pending collaborative reimbursement request, and generate the final approval decision result of the collaborative reimbursement request with risk warnings.

[0007] As a further aspect of the present invention, in step S1, receiving a collaborative reimbursement request event containing multi-party participation identifiers and expense details, and extracting the type code of the reimbursement business activity specifically includes: Parse the event data packet of the collaborative expense reimbursement request to obtain the list of expense items, invoice information and expense reimbursement business reason text. Based on the preset business scenario keyword library and semantic matching rules, scan the business reason text to extract the set of related candidate business scenarios. A business scenario classification model trained based on historical approval data is invoked. The classification model takes the semantic vectors of the expense item list and the business reason text as input, and outputs the confidence score of each category in the candidate business scenario set. The business scenario category with the highest confidence score is selected, and the standardized code corresponding to the business scenario category is used as the type code of the business activity of this collaborative reimbursement request.

[0008] As a further aspect of the present invention As a further aspect of the present invention, in step S2, the unit for retrieving the predicate logic form of the fee approval rule specifically includes: Based on the identifiers of each participant and the code of the business activity type, obtain the original approval rule text of each participant in the corresponding business scenario in the form of a combination of natural language and data fields; Based on the local rule engine structure, the original approval rule text is semantically parsed to identify entities, operators and constraints, and mapped into structured rule element triples. A preset predicate logic generation template is applied to assemble the rule element triples into a standard predicate logic expression composed of atomic predicates connected by logical connectors. Each expression corresponds to an independent fee approval rule unit. The generated standard predicate logic expression, combined with the participant identifiers from which it originates, is used to construct a rule subgraph structure that matches this collaborative expense reimbursement request, and the collaborative rule knowledge graph is dynamically updated.

[0009] As a further aspect of the present invention, in step S3, the fee approval rule units of each participating party are input into a conflict detection process based on forward chain reasoning. The logical conflicts between the fee approval rule units in the conflict detection results are resolved, and a conflict-free joint execution rule set is output. Specifically, this includes: Using atomic predicates in the cost approval rule unit as initial facts to drive the forward chain reasoning process, a set of conclusive assertions about the cost attribution subject, the sharing ratio, and the required approval node sequence are derived from the rule units of each participant. Identify assertion pairs in the set of conclusive assertions that point to the same business fact and are mutually exclusive, forming an initial set of conflicting pairs. Query the collaborative rule knowledge graph to record the historical execution frequency and cross-departmental collaboration adoption rate of each participant's expense approval rule unit, and generate dynamic rule weight indicators. Based on the dynamic rule weight index, all initial conflict pairs are quantitatively evaluated. The fee approval rule unit corresponding to the party with the higher weight is selected as the retained rule. The retained rule is merged with all fee approval rule units that have not conflicted and reorganized into a logically consistent set of conflict-free joint execution rules.

[0010] As a further aspect of the present invention, in step S4, the process of decoupling and recombining the costs and invoice information of the collaborative reimbursement request according to the joint execution rule set, and generating a sub-approval task corresponding to each participating party and bearing a globally unified event identifier, specifically includes: The specific proportion parameters of cost sharing defined for each participant in the joint enforcement rules set are analyzed. At the same time, according to the invoice compliance requirements specified in the joint enforcement rules set, the original invoice information is matched and bound with the amount to be borne by each party after splitting, forming a combined data block of invoice and amount. A unique global unified event identifier is generated for this collaborative expense reimbursement request. The combined data block, participant identifier, and global unified event identifier are encapsulated to construct a sub-approval task data package.

[0011] As a further aspect of the present invention, in step S5, distributing the sub-approval tasks to the local rule engines of each participating party for compliance verification, and binding the approval results and rule trigger sequences in the approval process with a globally unified event identifier before returning them specifically includes: Extract the data block combining the participant identifier and the corresponding invoice amount from the generated sub-approval task data packet, and send the sub-approval task back to the corresponding local rule engine according to the participant identifier; The local rules engine validates the invoice elements, amount elements, and approval path elements, summarizes the order of the triggered expense approval rule unit identifiers as the rule trigger sequence, and the approval results of sub-approval tasks, associates and encapsulates them with the globally unified event identifier, forms approval feedback data, and returns it.

[0012] As a further aspect of the present invention, in step S6, the risk identification model for establishing the collaborative reimbursement execution mode specifically includes: Based on the globally unified event identifier of historical collaborative reimbursement requests, the approval results returned by each participant are associated with and time-aligned with the rule trigger sequence to construct a historical cross-subject execution trajectory containing the rule triggering order, triggering subject, and approval conclusion, and the trajectory feature set of the failed execution trajectory is extracted. Based on multiple failed execution trajectories formed under the same business activity type code in historical collaborative expense reimbursement requests, failure modes are distinguished. Failed execution trajectories with the same trajectory characteristics are grouped into the same failure mode, and predefined business expense reimbursement risk category identifiers are associated with different failure modes to establish a risk identification model for collaborative expense reimbursement execution modes.

[0013] As a further aspect of the present invention, in step S7, generating the final approval decision result of the collaborative reimbursement request carrying risk warnings specifically includes: Based on the globally unified event identifier of the current collaborative reimbursement request pending approval, the approval results of the sub-approval tasks of each participating party under the same collaborative reimbursement request are aggregated, and the consistency of the approval conclusions of all sub-approval tasks is determined. Once the consistency check passes, the final approval result for the collaborative expense reimbursement request is generated; When the consistency determination fails, the cross-entity execution trajectory of the current collaborative reimbursement request to be approved is extracted and input into the risk identification model of the collaborative reimbursement execution mode. The corresponding business reimbursement risk category identifier is matched and identified, and the final approval failure result of the collaborative reimbursement request is generated, and the corresponding risk warning information is marked.

[0014] The technical effects and advantages of the intelligent approval method for financial shared expense reimbursement based on a rule engine in this invention are as follows: This invention addresses the problems of fragmented rules, frequent conflicts, and untraceable approval processes in multi-party collaborative expense reimbursement scenarios. By introducing a rule engine collaboration mechanism and execution trajectory analysis method, it enables conflict detection and resolution of expense approval rules from different participants within a unified framework, avoiding the inefficiency and compliance risks associated with manual coordination. Through the decomposition of sub-approval tasks and the unified management of global event identifiers, the entire collaborative expense reimbursement process possesses a clear execution path and traceability, facilitating stable operation in complex expense sharing scenarios. Furthermore, by constructing cross-party execution trajectories based on approval results and rule trigger sequences, and identifying risks based on failure trajectory patterns, the system moves beyond simply judging "whether it passes" to identifying potential business risks hidden within the approval process structure, providing targeted risk alerts for financial managers. The overall solution simultaneously improves collaborative approval efficiency, process transparency, and risk perception capabilities without altering the existing approval rule systems of each participant, making it suitable for complex financial sharing application scenarios such as group-based and multi-organizational collaborations. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of a financial shared expense reimbursement intelligent approval method based on a rule engine according to the present invention. Detailed Implementation

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

[0017] Example 1, Figure 1 This invention presents a smart approval method for financial shared expense reimbursement based on a rule engine, which includes the following steps: S1. Receive a collaborative expense reimbursement request event containing multi-party participation identifiers and expense details, and extract the type code of the expense reimbursement business activity; S2. Based on the type code and the identifier of each participant, retrieve the fee approval rule unit in predicate logic form from the collaborative rule knowledge graph built on the local rule engine of each participant; S3. Input the fee approval rule units of each participant into the conflict detection process based on forward chain reasoning, resolve the logical conflicts between the fee approval rule units in the conflict detection results, and output a set of conflict-free joint execution rules. S4. Based on the joint execution rule set, decouple and reorganize the cost and invoice information of the collaborative reimbursement request to generate sub-approval tasks that correspond to each participant and are accompanied by a globally unified event identifier. S5. Distribute the sub-approval tasks to the local rule engines of each participant for compliance verification, bind the approval results and rule trigger sequences in the approval process with the globally unified event identifier, and then return. S6. Based on the globally unified event identifier, extract the approval results and rule trigger sequences to perform cross-entity execution trajectories. Perform structured analysis on the rule trigger sequence offset, repeated trigger distribution and failure node position in the cross-entity execution trajectory of the failed sub-approval task approval results to form a trajectory feature set of the failed execution trajectory and establish a risk identification model for the collaborative reimbursement execution mode. S7. Identify the risks of the collaborative reimbursement execution mode corresponding to the currently pending collaborative reimbursement request, and generate the final approval decision result of the collaborative reimbursement request with risk warnings.

[0018] In step S1, a collaborative reimbursement request event containing multi-party participation identifiers and expense details is received, and the type code of the reimbursement business activity is extracted.

[0019] Collaborative expense reimbursement requests enter the financial shared service approval process in the form of event data packets. These event data packets contain at least three core elements: a list of expense items, invoice information, and a text explaining the reason for the expense reimbursement. The expense item list describes the composition of the expenses involved in the reimbursement, including the expense name, expense category, and corresponding amount. The invoice information reflects the supporting documentation for the expenses, including the invoice type, issuing entity, and invoice summary. The text explaining the reason for the expense explains the business background and purpose of the expense; it is typically filled out by the person making the expense reimbursement in natural language, and its length and expression vary considerably. For these event data packets, a structured parsing process is first performed to extract the expense item list, invoice information, and reason for the expense fields. The reason for the expense text is then segmented and standardized to eliminate irrelevant symbols and repetitive expressions, retaining only the core text content that reflects the business semantics. Subsequently, based on a pre-defined business scenario keyword library and semantic matching rules, the standardized business matter text is scanned segment by segment. The business scenario keyword library consists of common business activity terms, industry jargon, and business phrases from historical expense reports, categorized according to different business scenarios, such as joint marketing activities, project collaboration travel, and joint training. Semantic matching rules are used to limit the contextual relationships and combinations of keywords in the text, avoiding misjudgment of business scenarios by a single keyword. During the scanning process, when a keyword combination that satisfies the semantic matching rules appears in the business matter text, the corresponding business scenario is marked as a candidate business scenario, and all matched business scenarios are aggregated to form a candidate business scenario set.

[0020] After obtaining the candidate business scenario set, a business scenario classification model trained based on historical approval data is further introduced to refine the determination of the candidate business scenarios. The business scenario classification model adopts a multi-layered structure, including at least a semantic feature extraction layer, a feature fusion layer, and a classification output layer. Specifically, the semantic feature extraction layer performs joint representation processing on the expense item list and the business reason text. Specifically, it converts the name and category information of each expense item in the expense item list into semantic representations, and concatenates them with the semantic representation of the business reason text after word vector encoding to form a unified semantic vector input. The feature fusion layer performs weighted combination processing on the above semantic vectors to highlight the inherent relationship between expense composition and business description. The classification output layer is used to score and output a score for each type of business scenario in the candidate business scenario set. The training process of this classification model is completed based on historical approval data. The training samples consist of completed collaborative reimbursement requests, and each sample contains an expense item list, a business reason text, and the corresponding confirmed business activity type code. During training, the internal parameters of the model are continuously adjusted through multiple iterations, so that the business scenario score output by the model gradually approximates the business activity type corresponding to the historical approval results. After training, in practical applications, the list of expense items corresponding to the current collaborative expense reimbursement request and the text of the business reason are input into the classification model. The model outputs a confidence score for each business scenario in the candidate business scenario set. Finally, based on the confidence score results, the business scenario category with the highest score is selected, and the standardized code corresponding to this business scenario category is determined as the business activity type code for this collaborative expense reimbursement request.

[0021] In step S2, the fee approval rule unit in predicate logic form is retrieved.

[0022] For the identified business activity type codes, and combining the identifiers of each participant in the collaborative expense reimbursement request, the source of the expense approval rules applicable to each participant in this business scenario is located one by one. The approval rules of each participant typically exist in a combination of natural language descriptions and structured data fields. For example, the rule clauses simultaneously include textual descriptions of expense types, amount ranges, invoice requirements, and approval levels, while the corresponding management configurations include associated field identifiers, approval node numbers, and responsible role information. During implementation, the corresponding rule storage location is first accessed based on the participant identifier. The set of approval rules matching the current business activity type code is then selected, and the rule clause text and its associated data fields are extracted together. To ensure the semantic integrity of the rules, the original rule expression is not split or rewritten during the extraction process, and the field descriptions, enumeration value descriptions, and constraint descriptions associated with the rule are also included in the original approval rule text.

[0023] After obtaining the original approval rule text, the rule content is uniformly parsed and processed based on the existing local rule engine structures of each participating party. The local rule engine structure includes rule condition description units, rule judgment units, and rule action description units. The rule condition description units define the applicable conditions for the occurrence of expenses, the rule judgment units describe the logical relationships between conditions, and the rule action description units describe the approval requirements or constraints corresponding to the fulfillment of conditions. During implementation, the original approval rule text is first semantically decomposed to identify the relevant business entities, such as expense type, expense amount, invoice attributes, and approval roles. Simultaneously, operators representing comparison and logical relationships, as well as constraints used to define the scope of rule application, are identified. Subsequently, the identified entities, operators, and constraints are mapped into structured rule element triples, where each triple explicitly represents a business object, a constraint relationship, and a constraint value. For the rule element triples, a preset predicate logic generation template is applied to convert them into atomic predicate forms. Based on the logical relationships described in the original rule text, multiple atomic predicates are combined using logical connectors to form a complete predicate logic expression. Each predicate logic expression fully describes a fee approval rule, forming an independent fee approval rule unit.

[0024] After generating expense approval rule units for each participant, these rule units are further associated with participant identifiers to construct a rule subgraph structure matching the current collaborative expense reimbursement request. Each expense approval rule unit is treated as a rule node, and the business entities involved in the rule are treated as entity nodes. Connection edges are established through constraints between rule units and entities, thus forming a local graph structure reflecting the internal structural relationships of the rules. Based on this, for the business activity type encoding involved in the current collaborative expense reimbursement request, only the rule units and their entity nodes associated with that encoding are selected to construct a rule subgraph for this collaborative expense reimbursement request. Subsequently, this rule subgraph is aligned with the existing collaborative rule knowledge graph constructed based on the rule subgraph. Newly added rule nodes or relationship nodes are supplemented and recorded, and the relationships of existing nodes are updated and labeled, so that the collaborative rule knowledge graph continuously reflects the latest organizational status of each participant's rules in different business scenarios.

[0025] In step S3, the fee approval rule units of each participant are input into the conflict detection process based on forward chain reasoning. The logical conflicts between the fee approval rule units in the conflict detection results are resolved, and a conflict-free joint execution rule set is output.

[0026] For each generated expense approval rule unit, the atomic predicates constituting the predicate logic expression are first extracted from each rule unit, and these atomic predicates are used as the initial fact set in the forward chain reasoning process. These atomic predicates explicitly describe the most basic judgment conditions or constraint facts in the expense approval rules, such as expense type attribution, expense-bearing entity limitations, invoice attribute requirements, or approval role conditions. Subsequently, based on the logical connections defined in the rule units, a line-by-line matching and expansion reasoning is performed on the initial fact set. When all atomic predicates contained in a rule unit are satisfied in the current fact set, the reasoning result corresponding to that rule unit is triggered. The reasoning results are recorded in the form of conclusive assertions. Each conclusive assertion explicitly describes a business judgment result, such as the entity to which an expense should be borne, the expense's sharing ratio among different participants, or the order of approval nodes required for the expense. As the forward chain reasoning continues, newly generated conclusive assertions are added to the fact set to further participate in the matching and derivation of subsequent rule units until no new rule units are triggered. Based on the forward chain reasoning process, a set of all conclusive assertions related to this collaborative reimbursement request is systematically derived from the multi-party rule units, so that the cost attribution, allocation method and approval path are presented in a clear and structured form.

[0027] After obtaining the set of conclusive assertions, a consistency check is performed on the set, focusing on identifying assertion pairs that point to the same business fact but have mutually exclusive content. For example, for the same expense item, different participating party rule units may deduce different expense-bearing entities, or provide different descriptions of the sharing ratio for the same expense item, or provide inconsistent approval node requirements for the same business fact. During implementation, conclusive assertions pointing to the same expense item or the same approval fact are grouped and compared. When it is found that assertions cannot be simultaneously true in terms of the expense-bearing entity, ratio description, or approval order, the corresponding assertion combination is recorded as the initial conflict pair set. For each initial conflict pair, the historical execution information recorded in the collaborative rule knowledge graph is further queried, including the actual execution frequency of the corresponding expense approval rule unit in historical collaborative reimbursement, and the proportion of records where it was adopted and successfully executed by other participating party rules in multi-party collaborative scenarios. The historical execution frequency is obtained by counting the number of times the rule unit was triggered and took effect in historical reimbursement requests, and the cross-departmental collaboration adoption rate is obtained by counting the proportion of times the rule unit was adopted in multi-partner collaborative approval without causing subsequent conflicts.

[0028] After generating dynamic rule weight indices, conflict resolution is performed on each initial conflict pair. For each cost approval rule unit involved in a conflict pair, its corresponding dynamic rule weight indices are read, and the conflicting parties are compared and evaluated. When the weight index of one rule unit is higher than that of another rule unit in the conflict pair, the rule unit with the higher weight is selected as the retained rule for that conflict pair, while the rule unit with the lower weight is marked as not participating in this joint execution. After evaluating all initial conflict pairs, all selected retained rules are merged with the cost approval rule units in the original set of conclusive assertions that have not experienced any conflicts. The rule order is then reorganized according to logical consistency requirements to form a conflict-free joint execution rule set. For example, in the reimbursement process for a joint marketing activity, Party A's rule unit deduced that Party A would bear 60% of the cost, while Party B's rule unit deduced that Party B would bear all the cost, creating a conflicting assertion. By querying the historical collaborative rule knowledge graph, it was found that Party A's rule had been successfully adopted multiple times in similar scenarios and its execution was stable, while Party B's rule had a lower adoption rate in cross-departmental collaborations. Therefore, in the conflict resolution process, Party A's rule was selected as the retained rule, and the final joint execution rule set determined that the cost would be shared according to the logic of Party A bearing 60% and Party B bearing 40%.

[0029] In step S4, the costs and invoice information of the collaborative reimbursement request are decoupled and recombined according to the joint execution rule set to generate a sub-approval task corresponding to each participant and with a globally unified event identifier.

[0030] Once the conflict-free joint execution rule set has been generated, the cost-sharing clauses explicitly stipulated for each participating party are first parsed. These cost-sharing clauses, indexed by the participant identifier, clearly describe the cost-sharing ratio for each participant under the current collaborative reimbursement request. During implementation, based on this ratio description, the cost items included in the collaborative reimbursement request are broken down, and each cost is calculated and allocated to the corresponding participating party according to the proportional relationship determined in the joint execution rule set. Simultaneously, the joint execution rule set also clearly specifies the compliance requirements for various costs regarding invoices, such as the limitations imposed by different participating parties on invoice type, invoice header, issuing entity, and the completeness of invoice content. For the aforementioned invoice compliance requirements, the original invoice information is verified and classified item by item, and invoice information meeting the same compliance requirements is matched with the corresponding cost-sharing results. During the matching process, the original attributes of the invoices are kept unchanged; only a clear correspondence is established between the invoice and the split cost amount, thus forming a combined data unit containing the invoice identifier, invoice summary information, and corresponding cost-sharing amount.

[0031] After constructing the combined data block of invoices and amounts, a unique globally unified event identifier is generated for this collaborative reimbursement request. This globally unified event identifier is used to uniformly identify and associate the same reimbursement request throughout the entire collaborative approval process. Its generation process combines and encodes elements such as the business activity type code of the current reimbursement request, the set of participant identifiers, and the reimbursement occurrence time, ensuring accurate identification of the same collaborative reimbursement event across different participants and approval stages. After generating the globally unified event identifier, for each participant, its corresponding combined data block of invoices and amounts, participant identifier, and the globally unified event identifier are encapsulated to form an independent sub-approval task data package. During the encapsulation process, the original semantics of each data element remain unchanged; they are only grouped into the same data package through a structured organization method, enabling the sub-approval task to fully reflect the participant's cost-bearing situation and associated invoice information in this collaborative reimbursement request.

[0032] In S5, the sub-approval tasks are distributed to the local rule engines of each participant for compliance verification. The approval results and the rule trigger sequence in the approval process are bound to the globally unified event identifier and then returned.

[0033] Once the sub-approval task data packets are generated, the internal structure of each packet is parsed to extract the participant identifier and the corresponding invoice amount combination data block. The participant identifier uniquely indicates the approval entity to which the sub-approval task belongs, while the invoice amount combination data block fully describes the amount of expenses the participant is required to bear in this collaborative reimbursement request and its corresponding invoice information. During extraction, the integrity of the invoice amount combination data block is maintained; no modifications are made to the original invoice attributes, amount splitting results, or invoice summary information. Only the data items are read and verified in a structured manner. Subsequently, based on the extracted participant identifier, the corresponding sub-approval task data packet is sent to the local rule engine processing entry configured by the participant, ensuring that each participant only receives sub-approval tasks relevant to itself. This distribution method ensures that approval tasks between different participants are isolated, and each participant's local rule engine only performs verification operations on expenses, invoices, and approval requirements within its own scope of responsibility. Simultaneously, a globally unified event identifier is transmitted along with the sub-approval task data packet to accurately associate the same collaborative reimbursement request during subsequent approval result collection and execution trajectory aggregation.

[0034] After a sub-approval task arrives at the local rule engine of the corresponding participant, the local rule engine performs verification processing on the received sub-approval task according to its existing approval rule structure. First, the invoice elements are verified, including invoice type, invoice header, issuing entity, and completeness of invoice content. The verification process strictly compares each item according to the invoice compliance conditions defined in the local rules to ensure that the invoice information meets the compliance requirements of the participant in the current business scenario. Next, the amount elements are verified, including the correspondence between the split amount and the expense item attributes. During the verification process, it checks whether the amount falls within the expense range defined by the local rules and whether it is consistent with the invoice amount, avoiding mismatches or inconsistent expense attributes. After completing the invoice and amount verification, the approval path elements are further verified. These elements describe the order of approval nodes and the configuration of approval roles that the sub-approval task needs to go through in the local approval process. During the verification process, based on the approval level requirements specified in the local rules for different expense types and amount ranges, it confirms whether the current sub-approval task fully covers the required approval nodes. The local rule engine records the corresponding fee approval rule unit identifier each time a rule is hit, and organizes them according to the order of triggering to form a complete rule trigger sequence. After all verification steps are completed, the approval result of the sub-approval task is generated, and the approval result, rule trigger sequence, and globally unified event identifier are associated and encapsulated to form structured approval feedback data and returned.

[0035] In S6, a risk identification model for the collaborative reimbursement execution mode is established.

[0036] For historical collaborative expense reimbursement requests, approval results and rule trigger sequences from different participants are centrally aggregated based on a globally unified event identifier corresponding to each request. This aggregation process uses the event identifier as a unique association index to link the approval conclusions and rule trigger records generated during the local approval processes of the same collaborative expense reimbursement request in different participants. Subsequently, the aggregated rule trigger sequences are aligned by execution time and sorted according to the actual order in which the rules are triggered. The sorting results clearly indicate the participating entity corresponding to each rule trigger and the approval conclusion status at the time of the trigger, thus forming a complete historical cross-entity execution trajectory reflecting the multi-participant approval process. For collaborative expense reimbursement requests with failed approval results, their corresponding cross-entity execution trajectories are further structured and parsed. This includes analyzing the rule trigger sequence offset, i.e., identifying differences in the order of rule triggers for similar businesses among different participants; statistically analyzing the distribution of repeated rule triggers, i.e., identifying concentrated segments where the same rule is triggered multiple times during the approval process; and locating the failure node, i.e., determining the rule trigger position where the first failure conclusion occurs in the approval process and the participating entity involved.

[0037] After generating trajectory feature representations for multiple failed execution trajectories, the process further narrows down the scope to the same business activity type encoding, and performs failure mode merging on these trajectories generated from historical collaborative expense reporting requests. Specifically, based on the rule triggering order structure, repeated triggering distribution structure, and failure node location structure contained in the trajectory feature representations, the similarity of the failed execution trajectories is determined. When multiple failed execution trajectories exhibit consistent or highly similar structural forms in the aforementioned structural feature dimensions, they are merged into the same failure mode. For example, if multiple failed execution trajectories all show that the invoice compliance rule is repeatedly triggered in the early stages of approval and ultimately fails, they are merged into the same failure mode; if multiple failed execution trajectories all show that rule order anomalies occur in the later stages of the approval path, leading to failure, they are merged into another failure mode. After merging the failure modes, each failure mode is associated with a predefined business expense reporting risk category identifier, such as rule path anomaly risk, invoice compliance concentration failure risk, and insufficient stability of collaborating entities risk. Rule path anomaly risk corresponds to a situation where the rule triggering order deviates significantly from the established approval path during the collaborative expense reporting approval process, indicating a business scenario where necessary approval nodes are circumvented or even non-compliant expenses are concealed through abnormal paths. Invoice compliance concentration failure risk corresponds to a situation where multiple expenses are rejected at the same stage in collaborative expense reporting due to issues with invoice type, header, or content, reflecting a business scenario where invoice preparation is not standardized or there are hidden dangers such as reuse or false reporting. Insufficient stability of collaborating entities risk corresponds to a situation where the same participant repeatedly becomes the source of failure during multi-entity collaborative expense reporting, which may indicate a business scenario where the entity has persistent risks in expense declaration, rule understanding, or internal control. Subsequently, based on the trajectory feature representation of the failed execution trajectory and the corresponding failure mode identifier, a risk identification model for the collaborative reimbursement execution mode is constructed. The risk identification model matches and distinguishes the structural features of the input failed execution trajectory with the merged failure modes, and outputs the corresponding failure mode and its associated business reimbursement risk category, thereby realizing business reimbursement risk identification based on the execution trajectory structure.

[0038] In step S7, a final approval decision result for the collaborative reimbursement request carrying risk warnings is generated.

[0039] Once all participating parties' sub-approval tasks corresponding to a collaborative expense reimbursement request have completed local rule engine verification and returned approval feedback data, the scattered approval feedback data is centrally aggregated based on the globally unified event identifier corresponding to the current collaborative expense reimbursement request. This aggregation process uses the globally unified event identifier as the sole association criterion, uniformly aggregating the approval results of all sub-approval tasks belonging to the same collaborative expense reimbursement request to ensure no cross-event or cross-request data is mixed in. Subsequently, a consistency determination process is performed on the aggregated sub-approval task approval results. The specific consistency determination method involves checking the approval conclusion identifier of each sub-approval task one by one to confirm whether all results have returned a pass conclusion. During the determination process, the specific approval criteria of each participating party's local rule engine are not re-evaluated; only the approval conclusions themselves are objectively compared to ensure the certainty and reproducibility of the consistency determination. When the consistency determination result shows that all sub-approval tasks have completed approval and all have returned a pass conclusion, it is determined that the current collaborative expense reimbursement request does not have any unresolved rule or compliance issues at the multi-party collaborative approval level. Based on the judgment result, the final approval result of the collaborative reimbursement request is generated, and the result is bound and recorded with the global unified event identifier for subsequent reimbursement entry, archiving or audit traceability processing.

[0040] When at least one sub-approval task returns a failure conclusion, it is determined that the current collaborative reimbursement request does not meet the consistency condition of all approvals being passed. At this point, the processing flow is not directly terminated; instead, the cross-entity execution trajectory formed during the approval process of the current collaborative reimbursement request is further extracted. This cross-entity execution trajectory is located using a globally unified event identifier and includes the rule triggering order, triggering entity, and corresponding approval conclusion information generated by each participant during the approval process. After extraction, this cross-entity execution trajectory is used as input data and fed into the constructed collaborative reimbursement execution mode risk identification model. Based on the rule triggering structure features contained in the trajectory, the risk identification model matches and judges the failure modes merged from the current execution trajectory and historical failed execution trajectories, identifying the business reimbursement risk category identifier, such as rule path anomaly risk, centralized failure risk of invoice compliance, or insufficient stability risk of collaborative entities. After completing the risk category identification, a final failure result for the collaborative reimbursement request is generated, and the identified risk category prompt information is simultaneously marked in this final approval result, so that the reason for the failure is no longer limited to a single rule failure but is clearly presented in the form of execution mode risk. The above processing method enables structured and understandable risk warning information to be output when collaborative expense reimbursement requests fail to pass approval, supporting subsequent management actions such as business rectification, rule optimization, or collaborative relationship assessment.

[0041] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or 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, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium can be a solid-state drive.

[0042] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software 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.

[0043] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0044] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0045] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0046] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0047] If the aforementioned functions 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 solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0048] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0049] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A rule-based intelligent approval method for financial shared expense reimbursement, characterized in that, Includes the following steps: S1. Receive a collaborative expense reimbursement request event containing multi-party participation identifiers and expense details, and extract the type code of the expense reimbursement business activity; S2. Based on the type code and the identifier of each participant, retrieve the fee approval rule unit in predicate logic form from the collaborative rule knowledge graph built on the local rule engine of each participant; S3. Input the fee approval rule units of each participant into the conflict detection process based on forward chain reasoning, resolve the logical conflicts between the fee approval rule units in the conflict detection results, and output a set of conflict-free joint execution rules. S4. Based on the joint execution rule set, decouple and reorganize the cost and invoice information of the collaborative reimbursement request to generate sub-approval tasks that correspond to each participant and are accompanied by a globally unified event identifier. S5. Distribute the sub-approval tasks to the local rule engines of each participant for compliance verification, bind the approval results and rule trigger sequences in the approval process with the globally unified event identifier, and then return. S6. Based on the globally unified event identifier, extract the approval results and rule trigger sequences to perform cross-entity execution trajectories. Perform structured analysis on the rule trigger sequence offset, repeated trigger distribution and failure node position in the cross-entity execution trajectory of the failed sub-approval task approval results to form a trajectory feature set of the failed execution trajectory and establish a risk identification model for the collaborative reimbursement execution mode. S7. Identify the risks of the collaborative reimbursement execution mode corresponding to the currently pending collaborative reimbursement request, and generate the final approval decision result of the collaborative reimbursement request with risk warnings.

2. The intelligent approval method for financial shared expense reimbursement based on a rule engine according to claim 1, characterized in that, In step S1, receiving a collaborative reimbursement request event containing multi-party participation identifiers and cost details, and extracting the type code of the reimbursement business activity specifically includes: Parse the event data packet of the collaborative expense reimbursement request to obtain the list of expense items, invoice information and expense reimbursement business reason text. Based on the preset business scenario keyword library and semantic matching rules, scan the business reason text to extract the set of related candidate business scenarios. A business scenario classification model trained based on historical approval data is invoked. The classification model takes the semantic vectors of the expense item list and the business reason text as input, and outputs the confidence score of each category in the candidate business scenario set. The business scenario category with the highest confidence score is selected, and the standardized code corresponding to the business scenario category is used as the type code of the business activity of this collaborative reimbursement request.

3. The intelligent approval method for financial shared expense reimbursement based on a rule engine according to claim 1, characterized in that, In step S2, the unit for retrieving the predicate logic form of the fee approval rule specifically includes: Based on the identifiers of each participant and the code of the business activity type, obtain the original approval rule text of each participant in the corresponding business scenario in the form of a combination of natural language and data fields; Based on the local rule engine structure, the original approval rule text is semantically parsed to identify entities, operators and constraints, and mapped into structured rule element triples. A preset predicate logic generation template is applied to assemble the rule element triples into a standard predicate logic expression composed of atomic predicates connected by logical connectors. Each expression corresponds to an independent fee approval rule unit. The generated standard predicate logic expression, combined with the participant identifiers from which it originates, is used to construct a rule subgraph structure that matches this collaborative expense reimbursement request, and the collaborative rule knowledge graph is dynamically updated.

4. The intelligent approval method for financial shared expense reimbursement based on a rule engine according to claim 1, characterized in that, In step S3, the fee approval rule units of each participating party are input into the conflict detection process based on forward chain reasoning. The logical conflicts between the fee approval rule units in the conflict detection results are resolved, and a conflict-free joint execution rule set is output, specifically including: Using atomic predicates in the cost approval rule unit as initial facts to drive the forward chain reasoning process, a set of conclusive assertions about the cost attribution subject, the sharing ratio, and the required approval node sequence are derived from the rule units of each participant. Identify assertion pairs in the set of conclusive assertions that point to the same business fact and are mutually exclusive, forming an initial set of conflicting pairs. Query the collaborative rule knowledge graph to record the historical execution frequency and cross-departmental collaboration adoption rate of each participant's expense approval rule unit, and generate dynamic rule weight indicators. Based on the dynamic rule weight index, all initial conflict pairs are quantitatively evaluated. The fee approval rule unit corresponding to the party with the higher weight is selected as the retained rule. The retained rule is merged with all fee approval rule units that have not conflicted and reorganized into a logically consistent set of conflict-free joint execution rules.

5. The intelligent approval method for financial shared expense reimbursement based on a rule engine according to claim 1, characterized in that, In step S4, based on the joint execution rule set, the costs and invoice information of the collaborative reimbursement request are decoupled and recombined to generate sub-approval tasks corresponding to each participant and bearing a globally unified event identifier. Specifically, this includes: The specific proportion parameters of cost sharing defined for each participant in the joint enforcement rules set are analyzed. At the same time, according to the invoice compliance requirements specified in the joint enforcement rules set, the original invoice information is matched and bound with the amount to be borne by each party after splitting, forming a combined data block of invoice and amount. A unique global unified event identifier is generated for this collaborative expense reimbursement request. The combined data block, participant identifier, and global unified event identifier are encapsulated to construct a sub-approval task data package.

6. The intelligent approval method for financial shared expense reimbursement based on a rule engine according to claim 1, characterized in that, In step S5, the sub-approval tasks are distributed to the local rule engines of each participating party for compliance verification. The approval results and the rule trigger sequences in the approval process are bound to a globally unified event identifier and then returned. Specifically, this includes: Extract the data block combining the participant identifier and the corresponding invoice amount from the generated sub-approval task data packet, and send the sub-approval task back to the corresponding local rule engine according to the participant identifier; The local rules engine validates the invoice elements, amount elements, and approval path elements, summarizes the order of the triggered expense approval rule unit identifiers as the rule trigger sequence, and the approval results of sub-approval tasks, associates and encapsulates them with the globally unified event identifier, forms approval feedback data, and returns it.

7. The intelligent approval method for financial shared expense reimbursement based on a rule engine according to claim 1, characterized in that, In S6, the risk identification model for establishing the collaborative reimbursement execution mode specifically includes: Based on the globally unified event identifier of historical collaborative reimbursement requests, the approval results returned by each participant are associated with and time-aligned with the rule trigger sequence to construct a historical cross-subject execution trajectory containing the rule triggering order, triggering subject, and approval conclusion, and the trajectory feature set of the failed execution trajectory is extracted. Based on multiple failed execution trajectories formed under the same business activity type code in historical collaborative expense reimbursement requests, failure modes are distinguished. Failed execution trajectories with the same trajectory characteristics are grouped into the same failure mode, and predefined business expense reimbursement risk category identifiers are associated with different failure modes to establish a risk identification model for collaborative expense reimbursement execution modes.

8. The intelligent approval method for financial shared expense reimbursement based on a rule engine according to claim 1, characterized in that, In step S7, generating the final approval decision result for the collaborative reimbursement request carrying risk warnings specifically includes: Based on the globally unified event identifier of the current collaborative reimbursement request pending approval, the approval results of the sub-approval tasks of each participating party under the same collaborative reimbursement request are aggregated, and the consistency of the approval conclusions of all sub-approval tasks is determined. Once the consistency check passes, the final approval result for the collaborative expense reimbursement request is generated; When the consistency determination fails, the cross-entity execution trajectory of the current collaborative reimbursement request to be approved is extracted and input into the risk identification model of the collaborative reimbursement execution mode. The corresponding business reimbursement risk category identifier is matched and identified, and the final approval failure result of the collaborative reimbursement request is generated, and the corresponding risk warning information is marked.

Images