An abnormality detection method, device, and equipment for service data and a medium

Abstract

This application provides a method, apparatus, device, and medium for anomaly detection of business data, relating to the field of enterprise data processing technology. The method includes: acquiring different business data from different business systems within an enterprise; performing entity alignment, semantic mapping, and association on the different business data to obtain different target business data and the relationships between them; based on the relationships between the target business data, using a pre-built multi-level verification model to perform multi-level matching verification on the different target business data to obtain verification results; when the verification pass status is "fail" and the anomaly dimension and anomaly features do not meet the configured dynamic tolerance strategy, the anomaly dimension and anomaly features are input into a pre-trained anomaly attribution inference model to obtain the current anomaly type and the current anomaly cause. This application can improve the coverage and accuracy of anomaly detection while enhancing the automation level of business data risk control and compliance verification.

Description

Technical Field

[0001] This application relates to the field of enterprise data processing technology, and more specifically, to a method, apparatus, device, and medium for detecting anomalies in business data. Background Technology

[0002] As enterprise IT infrastructure development deepens, business data such as contracts, purchase orders, invoices, and payments are generated and managed independently by different business systems. These systems exhibit significant differences in data structure, field definitions, and naming conventions, resulting in typical multi-source heterogeneous business data. During cross-system business verification, existing methods often rely on manual verification or simple keyword matching, which struggles to achieve unified entity alignment and semantic association for heterogeneous business data. This makes it impossible to establish accurate relationships between different business data, leading to inefficient business data consistency verification and frequent misjudgments. Summary of the Invention

[0003] The purpose of this application is to provide a method, apparatus, device, and medium for detecting anomalies in business data, which solves the above-mentioned problems existing in the prior art. It can improve the coverage and accuracy of anomaly detection, reduce the dependence on human experience, and enhance the automation level of business data risk control and compliance verification.

[0004] Firstly, a method for detecting anomalies in business data is provided, which may include: Acquire different business data from different business systems within an enterprise; Entity alignment, semantic mapping, and association are performed on different business data to obtain different target business data and the association relationships between each target business data. Based on the correlation between the target business data, a pre-built multi-level verification model is used to perform multi-level matching verification on different target business data to obtain verification results; wherein, the verification results include: verification pass status, abnormal dimension and abnormal characteristics; When the verification status is "failed" and neither the anomaly dimension nor the anomaly feature satisfies the configured dynamic tolerance strategy, the anomaly dimension and anomaly feature are input into the pre-trained anomaly attribution inference model to obtain the current anomaly type and the current anomaly cause.

[0005] In an optional implementation, the business system includes: a contract system, a supply chain system, a tax system, and a financial system; The business data of the contract system includes: contract number, supplier name, total contract amount including tax, payment terms text, and detailed bill of materials; The business data of the supply chain system includes: purchase order number, current business status, material code, purchase quantity, material name, purchase unit price, quantity received, and warehousing date; The business data of the tax system includes: invoice code, invoice number, invoice date, buyer's tax ID, seller's tax ID, buyer's name, seller's name, goods details, and description text; The business data of the funds system includes: payment application number, proposed payment amount, receiving account, associated contract number, and associated order number.

[0006] In an optional implementation, entity alignment, semantic mapping, and association are performed on different business data to obtain different target business data and the association relationships between them, including: Different business data are input into a pre-trained business entity recognition and alignment model to obtain the target business data corresponding to the different business data. Calculate the similarity matrix between different target business data; Target business data that meets the configured filtering rules is filtered from the similarity matrix of different target business data to obtain the initial association relationship between each target business data. Construct a business heterogeneity diagram based on different target business data and the initial relationships between each target business data; The heterogeneous business graph is input into a pre-trained relational graph convolutional network to obtain the correlation between various target business data.

[0007] In an optional implementation, before performing multi-level matching verification on different target business data using a pre-built multi-level verification model based on the correlation between the target business data, the method further includes: For any contract number, filter the target purchase order numbers associated with the contract number based on the relationships between the target business data; The current business status corresponding to the target purchase order number is taken as the target business status; Match the target verification level corresponding to the target service state from the reference table of different target service states and different verification levels.

[0008] In an optional implementation, the multi-level matching verification includes: amount verification, line item verification, entity verification, and timing logic verification; Based on the relationships between the target business data, a pre-built multi-level verification model is used to perform multi-level matching verification on different target business data, including: For any contract number, based on the correlation between target business data, filter the target purchase order number, target payment application number, and target invoice number associated with the contract number; Based on the target verification level, the target purchase order number, the target payment application number, and the target invoice number, extract the data to be verified from each target business data; The pre-built multi-level verification model is used to perform matching verification of the data to be verified at the target verification level to obtain the verification result.

[0009] In an optional implementation, after obtaining the verification result, the method further includes: For any target business data whose verification status is not passed, the abnormal type corresponding to the abnormal dimension of the target business data is matched according to the configured lookup table of different abnormal dimensions and different abnormal types; the abnormal type includes quantity difference and amount difference. An exception instance is generated based on the exception type and the exception characteristics corresponding to the target business data; For any abnormal instance, if the abnormal type of the abnormal instance is quantity difference and amount difference, then check whether the abnormal instance meets the configured dynamic tolerance strategy. If the abnormal instance meets the configured dynamic tolerance policy, the verification status of the target business data corresponding to the abnormal instance will be corrected to "passed".

[0010] In an optional implementation, the anomaly dimension and anomaly features are input into a pre-trained anomaly attribution inference model to obtain the current anomaly type and the current anomaly cause, including: For any abnormal instance that does not meet the dynamic tolerance strategy, the current cause of the abnormality of the target business data corresponding to the abnormal instance is determined according to the attribution tree corresponding to the abnormality type of the abnormal instance. The exception type corresponding to the exception instance is determined as the current exception type of the target business data.

[0011] Secondly, an anomaly detection device for business data is provided, the device may include: The acquisition unit is used to acquire different business data from different business systems within an enterprise. The association unit is used to perform entity alignment, semantic mapping and association of different business data to obtain different target business data and the association relationship between each target business data. The verification unit is used to perform multi-level matching verification on different target business data based on the correlation between each target business data and a pre-built multi-level verification model to obtain the verification result; wherein, the verification result includes: verification pass status, abnormal dimension and abnormal characteristics. An anomaly analysis unit is used to input the anomaly dimension and anomaly feature into a pre-trained anomaly attribution inference model when the verification pass status is not passed and the anomaly dimension and the anomaly feature do not meet the configured dynamic tolerance strategy, so as to obtain the current anomaly type and the current anomaly cause.

[0012] Thirdly, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements any of the steps described in the first aspect above.

[0013] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of any of the methods described in the first aspect above.

[0014] This application employs entity alignment and semantic mapping to achieve unified association of multi-source business data, breaking down matching barriers caused by differences in data formats, naming, and representations across different business systems. This enhances the completeness and accuracy of business data association, laying a reliable data foundation for subsequent anomaly verification. Through a multi-level verification model, hierarchical matching verification can be conducted, simultaneously outputting verification status, anomaly dimensions, and anomaly features. Compared to single-result judgment, this achieves refined extraction of anomaly information, significantly improving the comprehensiveness and accuracy of anomaly identification. This application combines a dynamic tolerance strategy to filter tolerable anomalies, avoiding invalid anomaly alarms and redundant processing, reducing system misjudgments and manual intervention costs, and improving the rationality and efficiency of anomaly detection. Furthermore, a pre-trained anomaly attribution reasoning model is introduced to automatically determine the type and reason the cause of anomalies exceeding the tolerance range, replacing manual investigation and analysis. This achieves intelligent and standardized anomaly attribution, significantly shortening the anomaly location cycle and improving the response speed and decision-making accuracy of business anomaly handling. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 An architecture diagram of a business data anomaly detection system provided in this application embodiment; Figure 2A flowchart illustrating a method for detecting anomalies in business data provided in an embodiment of this application; Figure 3 A schematic diagram of the structure of a business data anomaly detection device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise defined, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art. The words "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are only used to distinguish different components. The words "comprising" or "including," etc., mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but do not exclude other elements or objects. The words "connected," "coupled," or "connected," etc., are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up," "down," "left," "right," etc., are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0018] The anomaly detection method for business data provided in this application embodiment can be applied to... Figure 1 In the system architecture shown, such as Figure 1As shown, the system may include: a server in the enterprise's backend and terminals for enterprise employees. The server can be a physical server, a server cluster composed of multiple physical servers, or a distributed system. It can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal may be a user equipment (UE) such as a mobile phone, smartphone, laptop, digital radio receiver, personal digital assistant (PDA), tablet computer (PAD), handheld device, in-vehicle device, wearable device, computing device, or other processing device connected to a wireless modem, mobile station (MS), mobile terminal, etc. The terminal and server can be directly or indirectly connected via wired or wireless communication methods; this application does not limit the connection.

[0019] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0020] Figure 2 This is a flowchart illustrating a method for detecting anomalies in business data provided in an embodiment of this application. Figure 2 As shown, the method may include: Step S210: Obtain different business data from different business systems of the enterprise.

[0021] The business systems include: a contract system, a supply chain system, a tax system, and a funds system. The contract system's business data includes: contract number, supplier name, total contract amount including tax, payment terms, and detailed bill of materials. The supply chain system's business data includes: purchase order number, current business status, material code, purchase quantity, material name, purchase unit price, received quantity, and warehousing date. The tax system's business data includes: invoice code, invoice number, invoice date, buyer's tax ID, seller's tax ID, buyer's name, seller's name, goods details, and description text. The funds system's business data includes: payment application number, proposed payment amount, receiving account, associated contract number, and associated order number.

[0022] Step S220: Perform entity alignment, semantic mapping, and association on different business data to obtain different target business data and the association relationships between each target business data.

[0023] In practice, different business data are input into a pre-trained business entity recognition alignment model to obtain target business data corresponding to different business data. Specifically, the material description of each contract line, the material code and material name of each order line, and the goods name of each invoice line are input into the business entity recognition alignment model to obtain the corresponding target business data, which is a semantic vector. A pre-trained and periodically self-evolving business entity recognition alignment model is used. This business entity recognition alignment model can be a semantic encoder (such as SimCSE-BERT). The initial version of the business entity recognition alignment model is pre-trained on the procurement domain corpus. Every week, positive sample pairs (contract line descriptions and order line descriptions, order line descriptions and invoice line descriptions that are finally matched) and negative sample pairs (description pairs with similar amounts under the same contract but not matched) automatically collected from historical settlement logs are compared and fine-tuned to continuously improve semantic discrimination ability. Calculate the similarity matrix between different target business data. Specifically, for invoice lines, if the order number extracted from the remarks column is not empty, directly search for order lines with the same purchase order number in the supply chain system to establish a direct association, with a matching confidence level of 1.0. Similarly, payment applications are directly bound through the associated order number or associated contract number. For contract lines, order lines, and invoice lines that are not directly associated, calculate the cosine similarity of pairwise semantic vectors to obtain three matrices: contract-order similarity matrix, order-invoice similarity matrix, and contract-invoice similarity matrix. Price and quantity filtering: Set a price tolerance ratio (e.g., 5%). If the difference between the unit price of the contract line and the unit price of the order line exceeds the configured price tolerance ratio, the similarity between the corresponding target business data is configured to 0. The same applies to order-invoice and contract-invoice. Quantity filtering: The number of invoice lines should not exceed the remaining unbilled quantity of the order line (purchase quantity - received quantity); otherwise, reduce the weight. From the similarity matrix of different target business data, target business data that meets the configured filtering rules are filtered to obtain the initial association between each target business data; specifically, all combinations of contract lines, order lines, and invoice lines are traversed; if all three similarities are greater than the configured similarity threshold, candidate triplet is generated, and the comprehensive score is calculated as 0.3 × contract-order similarity + 0.4 × order-invoice similarity + 0.3 × contract-invoice similarity. Based on the different target business data and the initial relationships between each target business data, a business heterogeneity graph is constructed. Specifically, the business heterogeneity graph is constructed as follows: nodes include all contract lines, order lines, and invoice lines; edges come from candidate triples, and the edge weights are the corresponding similarities. The heterogeneous business graph is input into a pre-trained relational graph convolutional network to obtain the relationships between various target business data. Specifically, a relational graph convolutional network (R-GCN) that learns to aggregate information from neighboring nodes is trained on a historically complete matching document graph. The heterogeneous business graph is input into the R-GCN and passed through two convolutional layers, with each node obtaining an enhanced semantic vector. Then, for each candidate triplet, the enhanced vectors of the three nodes are concatenated and input into a multilayer perceptron (MLP), outputting a matching probability (0~1). An integer programming problem is solved: the variable is whether each candidate triplet is selected, the constraint is that each node is selected at most once, and the objective is to maximize the sum of the matching probabilities of the selected triplets. The optimal matching set is obtained using the Hungarian algorithm or OR-Tools. For triples in the optimal matching set with a matching probability lower than 0.6, their information entropy is calculated, and the top 3 with the highest entropy are selected. For each selected triple, a natural language question is generated, and the responses from company employees to the natural language question are received. If the response is positive, the match is fixed, and the probability is increased to 1.0. If the response is negative, the probability of the triple is set to 0. Integer programming is then performed again (under the fixed constraints) until all matching probabilities are ≥0.6 or the user terminates. Each match in the final matching set is output as an associated record: contract number, contract line number, purchase order number, order line number, invoice number, invoice line number, and target confidence score. An isolated row list is also output: unmatched contract lines, order lines, and invoice lines.

[0024] In one embodiment of this application, before performing entity alignment, semantic mapping, and association on different business data, the method may further include: The bill of materials details in the contract system are split into multiple contract lines; each contract line may include: contract number, first line number, material description, first quantity, first unit price, and first amount (the product of the first quantity and the first unit price); at the same time, the supplier name, total contract amount including tax, and payment terms corresponding to the contract number are retained; Each material code under each purchase order number in the supply chain system is split into an order line; any order line may include: purchase order number, second line number, material code, material name, purchase quantity, purchase unit price, quantity received, warehousing date, and second amount; Each item in the tax system is broken down into invoice lines. Each invoice line can include: invoice number, third line number, item name, second quantity, second unit price, tax rate, and third amount (total price including tax or net amount). At the same time, the seller's name, seller's tax number, and invoice date corresponding to the invoice number are retained, and the order number in the remarks column is extracted by regular expression (if it exists). For each payment request in the funds system, retain the following information: payment request number, proposed payment amount, payee account, relevant contract number, and associated order number.

[0025] Step S230: Based on the correlation between the target business data, use the pre-built multi-level verification model to perform multi-level matching verification on the different target business data to obtain the verification results.

[0026] The multi-level matching verification includes: amount verification, line item verification, entity verification, and timing logic verification.

[0027] In one embodiment of this application, before performing multi-level matching verification on different target business data using a pre-built multi-level verification model based on the correlation between each target business data, the method may further include: For any given contract number, filter the target purchase order numbers associated with the contract number based on the relationships between the target business data; The current business status corresponding to the target purchase order number is taken as the target business status; the current business status can be: pending receipt, partial receipt, receipt completed, pending invoicing, partial invoicing, invoicing completed, pending payment or payment completed; From the reference table of different target business states and different verification levels, the target verification level corresponding to the target business state is matched; specifically, if the target business state is pending receipt or partial receipt, invoice-related verification is not performed, only order and contract verification and isolated line processing are performed; if the target business state is receipt completed and invoice pending, quantity, unit price and amount verification are performed, but tax rate verification and timing verification are skipped; if the state is invoice completed, pending payment or payment completed, all verifications are performed.

[0028] In practice, for any contract number, the target purchase order number, target payment application number, and target invoice number associated with the contract number are filtered based on the relationship between the target business data. Based on the target verification level, target purchase order number, target payment application number, and target invoice number, extract the data to be verified from each target business data. Specifically, the order line containing the target purchase order number is taken as the target order line; the sum of the second amounts corresponding to each target order line is taken as the cumulative order amount of the contract; the invoice line containing the target invoice number is taken as the target order line; the sum of the third amounts corresponding to each target invoice line is taken as the cumulative invoice amount of the contract; each payment application containing the target payment application number is taken as the target payment application; and the sum of the proposed payment amounts corresponding to each target payment application is taken as the cumulative payment amount of the contract. The pre-built multi-level verification model is used to perform matching verification of the data to be verified at the target verification level to obtain the verification result. Specifically, a multi-level verification model is used to check whether the cumulative order amount, cumulative invoice amount, and cumulative payment amount of the contract meet the total amount constraint; if the cumulative order amount of the contract is greater than the total amount including tax (obtained from the original data of the contract line), the anomaly dimension is recorded as the total amount difference. Orders exceeding the limit are considered anomalies, with an exception count including the absolute value and percentage of the excess (excess amount / total contract amount including tax). If the total invoice amount of the contract exceeds the total order amount of the contract, the anomaly is recorded as the total difference. Excessive invoice amount; abnormal characteristics include the absolute value and percentage of the excess; if the total contract payment amount > the total contract invoice amount, the abnormal dimension is recorded as the total amount difference. Payment exceeding the limit is characterized by both the absolute value and percentage of the excess amount; if all the above checks pass, the total amount constraint is satisfied. For each triplet (contract line, order line, invoice line) in the relationship list, based on the contract number and contract line number, retrieve the quantity, unit price, amount, and tax rate of the contract line from the original contract line data; based on the purchase order number and second line number, retrieve the purchase quantity, purchase unit price, and second amount of the order line; based on the invoice number and third line number, retrieve the second quantity, second unit price, third amount, and tax rate of the invoice line; compare the invoice line quantity with the order line purchase quantity; if they are not equal, calculate the difference = invoice quantity - order quantity, the ratio = |difference| / order quantity, and record the anomaly dimension as line item difference. Inconsistent quantities indicate anomalies with the following characteristics: contract number, purchase order number, invoice number, respective quantities, difference, and percentage. Compare the unit price in the invoice line with the purchase unit price in the order line; if they are not equal, calculate the difference and percentage, and record the anomaly as a line item difference. Inconsistent unit prices are identified by anomaly characteristics including unit price differences and percentages; compare the invoice line amount with the order line amount. If they are not equal, record the anomaly as line item difference. Inconsistent amounts indicate anomalies involving both amount differences and percentage variations. Compare the contract line tax rate (or default value) with the invoice line tax rate; if they are not equal, record the anomaly dimension as "Line Item Difference". "Inconsistent tax rates" is an anomaly that includes both contract tax rates and invoice tax rates. For each triple in the relationship list, obtain the supplier name from the original contract line data, the seller name from the original invoice line data (or query the company name through the seller's tax ID), find the payment application number bound to the contract number or purchase order number from the payment binding list, obtain the receiving account from the payment application, and query the account holder name corresponding to the account through the enterprise bank account information table to obtain the payment entity; compare the contract entity with the invoice entity: if they are completely identical or the fuzzy match similarity is >0.85, then it passes; otherwise, query the tripartite entrustment agreement database: whether there is a valid agreement (the entrusting party = the contract entity, the entrusted party = the invoice entity, and the current date is within the validity period). If it exists, mark it as tripartite agreement coverage, consistent; otherwise, record the abnormal dimension as entity difference. The contract and invoice entities do not match. Anomalies include discrepancies in the contract entity, invoice entity, whether an agreement was attempted, and the result. Compare the contract entity with the payment entity: if they do not match and there is no valid agreement (the client = contract entity, the agent = payment entity), record the anomaly as entity difference. The contract and the payment entity do not match; compare the invoice entity with the payment entity: if they do not match and there is no valid agreement (the principal = the invoice entity, the agent = the payment entity), record the anomaly as entity difference. The invoice does not match the payee; For each triple in the relationship list, retrieve the date and payment period: Inbound date: Retrieve the inbound date from the order line (or use the order creation date if none exists); Invoice date: Retrieve the invoice date from the invoice line; Extract the payment period from the payment terms in the original contract line data (e.g., extract 30 days for "delivery in 30 days"; default to 0 if none exists), obtaining the payment period days; Find the corresponding payment request in the payment binding list and retrieve the request date (skip this step if the payment request has not arrived); Verify if the invoice date is earlier than the inbound date: If the invoice date < the inbound date, record the exception dimension as a time-series exception. If an invoice is received before the goods are received, the anomaly characteristics include the goods receipt date, invoice date, and number of days prior to receipt. Verify if the payment date is earlier than the due date (only if a payment request exists), and calculate the theoretical due date as invoice date + payment period days. If the payment request date is less than the theoretical due date, record the anomaly as a time-series anomaly. For advance payments, the unusual characteristics include the theoretical due date, the actual payment application date, and the number of days in advance. For each isolated contract line: the anomaly dimension is the isolated contract line, and the anomaly characteristics include: contract number, line number, material description, quantity, amount, and supplier name; for isolated order lines: the anomaly dimension is the isolated order line, and the anomaly characteristics include: purchase order number, line number, material code, purchase quantity, quantity received, and amount; for isolated invoice lines: the anomaly dimension is the isolated invoice line, and the anomaly characteristics include: invoice number, line number, goods name, quantity, amount, seller name, and invoice date.

[0029] In another embodiment of this application, the method may further include: When multiple invoice lines exist under the same purchase order number, or multiple order lines exist under the same invoice number, the output association may not be optimal. In this case, extract all associated order lines and invoice lines under the purchase order number, and use the subset sum algorithm (or Hungarian algorithm) to resolve for the best match. Specifically, use the quantity / amount of order lines as the supply vector and the quantity / amount of invoice lines as the demand vector. Within the allowed tail difference (e.g., 0.01 yuan), find a pair that minimizes the total matching error. If the solution result is inconsistent with the current association, update the association and record the abnormal dimension as a line item matching adjustment. The abnormal feature includes the correspondence before and after the adjustment.

[0030] Step S240: When the verification status is not passed and the abnormal dimension and abnormal features do not meet the configured dynamic tolerance strategy, the abnormal dimension and abnormal features are input into the pre-trained abnormal attribution inference model to obtain the current abnormal type and the current abnormal cause.

[0031] In practice, for any abnormal instance that does not meet the dynamic tolerance strategy, the current cause of the abnormality of the target business data corresponding to the abnormal instance is determined according to the attribution tree corresponding to the abnormality type of the abnormal instance. Different judgment rules are pre-defined for different abnormality types, and the current cause of the abnormality of the target business data corresponding to the abnormal instance is determined according to whether the abnormal instance meets the corresponding judgment rules. The exception type corresponding to the exception instance is determined as the current exception type of the target business data.

[0032] In one embodiment of this application, after obtaining the verification result, the method may further include: For any target business data whose verification status is "passed" or "failed", match the anomaly type corresponding to the anomaly dimension of the target business data according to the configured lookup table for different anomaly dimensions and different anomaly types; the anomaly types include quantity difference and amount difference; specifically, if the anomaly dimension is line item difference... If the quantities are inconsistent, the anomaly type is quantity difference; if the anomaly dimension is row item difference... If the amounts are inconsistent, the exception type is "amount difference"; if the exception dimension is "line item difference". If the unit price is inconsistent, the anomaly type is "unit price difference". If the anomaly dimension is "row item difference", then... If tax rates are inconsistent, the anomaly type is "tax rate difference." If the anomaly dimension begins with "subject difference," the anomaly type is "heading difference." If the anomaly dimension is a time-series anomaly... If the invoice is received before the goods are put into storage, the exception type is "time sequence difference" (invoice received before goods are put into storage). If the exception dimension is "time sequence exception"... If payment is made in advance, the anomaly type is time-series difference (early payment). If the anomaly dimension is total amount difference... If the order exceeds the limit, the exception type is "Total Amount Exceeded". If the exception dimension is "Total Amount Difference", then the exception type is "Total Amount Difference". If the invoice amount exceeds the limit, the exception type is "total amount exceeding the limit". If the exception dimension is "total amount difference", then... If the payment exceeds the limit, the exception type is "Total Amount Exceeded". If the exception dimension is an isolated contract line, the exception type is "Orphaned Contract". If the exception dimension is an isolated order line, the exception type is "Orphaned Order". If the exception dimension is an isolated invoice line, the exception type is "Orphaned Invoice".

[0033] An anomaly instance is generated based on the anomaly type and the anomaly characteristics corresponding to the target business data. The anomaly instance may include: anomaly type; associated document identifiers: contract number (if any), purchase order number, and invoice number; supplier number (obtained from the contract or order); supplier level (obtained by querying the supplier master data using the supplier number); material number (obtained from the order line, if applicable); material category (obtained by querying the material master data using the material number); order amount (obtained from the order line, used to determine the scale of the tail difference threshold); anomaly ratio (applicable only to quantity and amount differences): quantity anomaly ratio = |invoice quantity - order quantity| / order quantity; amount anomaly ratio = |invoice amount - order amount| / order amount (only for tail difference scenarios, usually the absolute value is very small); absolute difference (absolute value of quantity difference or absolute value of amount difference). For any abnormal instance, if the abnormality type is quantity difference or amount difference, then it is checked whether the abnormal instance meets the configured dynamic tolerance strategy. The dynamic tolerance strategy table stores the quantity over / under shipment ratio threshold and amount difference threshold according to dimensions such as supplier level, material category, and order amount. The generation method of the dynamic tolerance strategy table may include: obtaining historical settlement logs (all abnormal records of quantity difference and amount difference processed in the past year, including abnormality ratio, supplier level, material category, order amount, final processing action, and subsequent risk events); for each combination of (abnormality type, supplier level, material category, amount range), Bayesian optimization is used to find the optimal threshold that minimizes the overall processing cost (manual time + risk cost); for example: for (quantity difference, strategic supplier, chemical raw materials, any amount), if historical data shows that cases with an abnormality ratio within ±6% are all manually exempted and risk-free, then the optimal threshold is set to 6%; if ±4% or more has led to returns, then it is set to 4%. For the amount difference, the optimal absolute difference (such as 0.02 yuan, 0.05 yuan, etc.) is learned according to the amount range. The dynamic tolerance strategy table can include: anomaly type (quantity difference / amount difference), supplier level, material category (only applicable to quantity difference), order amount lower limit, order amount upper limit, tolerance threshold (proportion or absolute value).

[0034] If the abnormal instance meets the configured dynamic tolerance policy, the verification status of the target business data corresponding to the abnormal instance will be corrected to passed. Iterate through each instance in the list of exception instances; if the exception type is quantity exception, retrieve the supplier level, material category, and exception percentage (absolute value) from the exception instance; query the dynamic tolerance strategy table for matching records: the search criteria are exception type = quantity exception, same supplier level, same material category. If found, obtain the system learning threshold (e.g., ±5%). If not found, use the system default threshold (e.g., ±0%); if the contract stipulated the contract over / under shipment ratio at the time of signing (extracted from the contract line data), the actual tolerance limit is min(contract-stipulated ratio, system learning threshold) (i.e., cannot exceed the contract stipulation). If the contract does not stipulate, directly use the system learning threshold; if the exception percentage ≤ tolerance limit, it is determined to be within the tolerance, set whether it is within the tolerance to yes, the final processing suggestion is automatic exemption, the tolerance source is = dynamic tolerance strategy table (quantity over / under shipment), and no attribution reasoning is performed; if the exception percentage > tolerance limit, it is determined to be outside the tolerance, and marked for attribution reasoning. If the anomaly type is an amount anomaly, retrieve the order amount (or invoice amount, whichever is larger) and absolute difference (|invoice amount - order amount|) from the anomaly instance. Based on the order amount size, query the corresponding absolute threshold for the amount difference from the dynamic tolerance strategy table (e.g., 0.01 yuan for order amount < 10,000, 0.05 yuan for 10,000-100,000, etc.). If not found, use the default threshold of 0.01 yuan. Compare whether the absolute difference is ≤ the amount difference threshold: if the absolute difference is not greater than the configured amount difference threshold, it is determined to be within the tolerance, and the setting is set to Yes, the final processing suggestion is Automatic Exemption, and the tolerance source is Dynamic Tolerance Strategy Table (Amount Amount Difference). No attribution reasoning is performed; if the absolute difference is greater than the configured amount difference threshold, it is determined to be outside the tolerance, and marked for attribution reasoning; for anomaly instances determined to be within the tolerance, they are directly added to the final diagnostic report, and no further attribution is performed. If the exception type is other (unit price exception, tax rate exception, header exception, timing exception, total amount excess, isolated contract, isolated order, isolated invoice), it will be marked as not within the tolerance.

[0035] In yet another embodiment of this application, the method may further include: For any abnormal instance, determine the corresponding routing rule; each routing rule matches a specific combination of (difference type, whether within tolerance, attribution cause) and specifies the action to be performed; simultaneously, routing rules support dynamic priority and adaptive adjustment; based on the action to be performed by the routing rule corresponding to the abnormal instance, call the corresponding subsystem interface or perform internal operations; the action to be performed may include: First, automatic exemptions (for amount discrepancies, quantity overages / shortages, policy tax rates, etc.): For amount discrepancies: automatically generate financial adjustment entries, debit / credit - discrepancy adjustment account, with the amount being the absolute value of the anomaly, and update the status of the four documents to "reconciled - automatic exemption"; For quantity overages / shortages (within tolerance): automatically generate quantity adjustment orders (such as overage / shortage confirmation orders), update the quantity received in the order, and mark the invoice line as matched; For tax rate anomalies (policy reasons): automatically record the policy exemption basis (policy document number, validity period) in the system, allowing the invoice to pass; For all automatic exemption anomalies, record the exemption log (operator = system, reason = dynamic tolerance strategy), and directly set the status of the corresponding document to payable; Second, forcibly reject invoices (invoice errors, non-compliant headers, invalid invoices, etc.), call the email service to query the contact person's email address based on the supplier number, and send a rejection notification template (containing the invoice number, reason for rejection, request for re-issuance, etc.); call the supplier portal interface (if applicable) to mark the invoice as invalid and prevent it from being submitted again; in the four-order model, set the status of the invoice line to rejected and record the rejection log; if necessary, automatically generate a return notification (for goods that have already been put into storage, trigger the return process).

[0036] Third, initiate the approval workflow (unit price change, supplementary agreement, price approval, etc.), determine the approval template based on the exception type and attribution reason; call the workflow engine (such as Activiti, Flowable) to create an approval instance, fill in the exception summary, document link, and suggested operation into the form; determine the approver (e.g., purchasing manager, financial director) according to business rules, and push the pending task through the client; record the approval instance ID, suspend the current settlement process, and wait for the approval result callback; after approval, the system automatically executes the corresponding changes (such as updating the order unit price, adding the contract total amount), and re-triggers the verification; if the approval is rejected, it is transferred to manual processing or rejected. Fourth, Virtual Red Invoice Reversal (Return Scenario): When the cause of the return is that no red invoice was generated, the system automatically generates a negative invoice line (red ink) in the four-document model: it copies the original invoice line information, sets the quantity and amount to negative values, and marks the document type as a virtual red ink invoice. The red ink invoice line is then linked to the original order line and the original invoice line, and the corresponding amount is automatically deducted from accounts payable (Debit: Accounts Payable Red Invoice, Credit: Inventory / Expenses Red Invoice). Upon the next payment, the system automatically adds the red ink amount to the accounts payable balance for offsetting; simultaneously, a notification is sent to the supplier. Fifth, push to-do items (manual confirmation scenarios). For exceptions requiring manual confirmation (such as warehouse replenishment of inbound orders, master data correction, and purchasing staff confirmation of goods arrival), call the to-do center interface to create a to-do task. The to-do item includes exception details, operation instructions, links to related documents, and specifies the handling role (warehouse administrator, purchasing staff, etc.). Set a timeout period (e.g., 24 hours), and automatically escalate after the timeout (e.g., notify superiors or convert to mandatory rejection). After manual processing is completed, the system receives a callback and decides on subsequent actions based on the processing result (e.g., re-verify after replenishment, or automatically waive after confirmation). Sixth, forcibly intercept payments. For timing anomalies such as advance payments, call the funds system interface to change the status of the payment application to frozen, preventing the generation of payment instructions; simultaneously push the approval pending task to the finance manager, explaining the reason for the interception, requiring manual unlocking; error handling during execution: if the call to the external interface fails (e.g., mail server unavailable, ERP interface timeout), the system records the error log and handles it according to the degradation action (e.g., transferring to the manual queue). If the degradation action is also empty, the exception record is marked as "routing failure" and an alarm is sent to the system administrator; It also generates the execution status (success / failure / pending approval / pending manual intervention) for each abnormal instance, as well as a summary of the execution results (such as the generated adjustment order number, approval instance ID, email sending ID, etc.).

[0037] Corresponding to the above method, embodiments of this application also provide an anomaly detection device for business data, such as... Figure 3As shown, the device includes: Acquisition unit 310 is used to acquire different business data from different business systems of the enterprise; The association unit 320 is used to perform entity alignment, semantic mapping and association on different business data to obtain different target business data and the association relationship between each target business data. The verification unit 330 is used to perform multi-level matching verification on different target business data based on the correlation between each target business data and using a pre-built multi-level verification model to obtain the verification result; wherein, the verification result includes: verification pass status, abnormal dimension and abnormal characteristics; The anomaly analysis unit 340 is used to input the anomaly dimension and anomaly features into the pre-trained anomaly attribution inference model when the verification status is not passed and the anomaly dimension and anomaly features do not meet the configured dynamic tolerance strategy, so as to obtain the current anomaly type and the current anomaly cause.

[0038] The functions of each functional unit of the business data anomaly detection device provided in the above embodiments of this application can be implemented through the above method steps. Therefore, the specific working process and beneficial effects of each unit in the business data anomaly detection device provided in the embodiments of this application will not be repeated here.

[0039] This application also provides an electronic device, such as... Figure 4 As shown, it includes a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440.

[0040] Memory 430 is used to store computer programs; When the processor 410 executes the program stored in the memory 430, it performs the following steps: Acquire different business data from different business systems within an enterprise; Entity alignment, semantic mapping, and association are performed on different business data to obtain different target business data and the association relationships between each target business data. Based on the correlation between the target business data, a pre-built multi-level verification model is used to perform multi-level matching verification on different target business data to obtain verification results; among which, the verification results include: verification pass status, abnormal dimension and abnormal characteristics; When the verification status is not passed and the abnormal dimension and abnormal features do not meet the configured dynamic tolerance strategy, the abnormal dimension and abnormal features are input into the pre-trained abnormal attribution inference model to obtain the current abnormal type and the current abnormal cause.

[0041] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0042] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0043] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0044] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0045] The implementation methods and beneficial effects of the various components of the electronic device in the above embodiments for solving the problem can be found in [reference needed]. Figure 2 The steps in the illustrated embodiments are used to implement the electronic device. Therefore, the specific working process and beneficial effects of the electronic device provided in this application will not be repeated here.

[0046] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform any of the above-described methods for detecting anomalies in business data.

[0047] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the above-described methods for detecting anomalies in business data.

[0048] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0049] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0050] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0051] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0052] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.

[0053] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of this application and its equivalents, then these modifications and variations are also intended to be included in the embodiments of this application.

Claims

1. A method for detecting anomalies in business data, characterized in that, The method includes: Acquire different business data from different business systems within an enterprise; Entity alignment, semantic mapping, and association are performed on different business data to obtain different target business data and the association relationships between each target business data. Based on the correlation between the target business data, a pre-built multi-level verification model is used to perform multi-level matching verification on different target business data to obtain verification results; wherein, the verification results include: verification pass status, abnormal dimension and abnormal characteristics; When the verification status is "failed" and neither the anomaly dimension nor the anomaly feature satisfies the configured dynamic tolerance strategy, the anomaly dimension and anomaly feature are input into the pre-trained anomaly attribution inference model to obtain the current anomaly type and the current anomaly cause.

2. The method as described in claim 1, characterized in that, The business systems include: a contract system, a supply chain system, a tax system, and a financial system; The business data of the contract system includes: contract number, supplier name, total contract amount including tax, payment terms text, and detailed bill of materials; The business data of the supply chain system includes: purchase order number, current business status, material code, purchase quantity, material name, purchase unit price, quantity received, and warehousing date; The business data of the tax system includes: invoice code, invoice number, invoice date, buyer's tax ID, seller's tax ID, buyer's name, seller's name, goods details, and description text; The business data of the funds system includes: payment application number, proposed payment amount, receiving account, associated contract number, and associated order number.

3. The method as described in claim 1, characterized in that, Entity alignment, semantic mapping, and association are performed on different business data to obtain different target business data and the relationships between them, including: Different business data are input into a pre-trained business entity recognition and alignment model to obtain the target business data corresponding to the different business data. Calculate the similarity matrix between different target business data; Target business data that meets the configured filtering rules is filtered from the similarity matrix of different target business data to obtain the initial association relationship between each target business data. Construct a business heterogeneity diagram based on different target business data and the initial relationships between each target business data; The heterogeneous business graph is input into a pre-trained relational graph convolutional network to obtain the correlation between various target business data.

4. The method as described in claim 2, characterized in that, Before performing multi-level matching verification on different target business data based on the correlation between each target business data using a pre-built multi-level verification model, the method further includes: For any contract number, filter the target purchase order numbers associated with the contract number based on the relationships between the target business data; The current business status corresponding to the target purchase order number is taken as the target business status; Match the target verification level corresponding to the target service state from the reference table of different target service states and different verification levels.

5. The method as described in claim 4, characterized in that, The multi-level matching verification includes: amount verification, line item verification, entity verification, and timing logic verification; Based on the relationships between the target business data, a pre-built multi-level verification model is used to perform multi-level matching verification on different target business data, including: For any contract number, based on the correlation between target business data, filter the target purchase order number, target payment application number, and target invoice number associated with the contract number; Based on the target verification level, the target purchase order number, the target payment application number, and the target invoice number, extract the data to be verified from each target business data; The pre-built multi-level verification model is used to perform matching verification of the data to be verified at the target verification level to obtain the verification result.

6. The method as described in claim 1, characterized in that, After obtaining the verification result, the method further includes: For any target business data whose verification status is not passed, the abnormal type corresponding to the abnormal dimension of the target business data is matched according to the configured lookup table of different abnormal dimensions and different abnormal types; the abnormal type includes quantity difference and amount difference. An exception instance is generated based on the exception type and the exception characteristics corresponding to the target business data; For any abnormal instance, if the abnormal type of the abnormal instance is quantity difference and amount difference, then check whether the abnormal instance meets the configured dynamic tolerance strategy. If the abnormal instance meets the configured dynamic tolerance policy, the verification status of the target business data corresponding to the abnormal instance will be corrected to "passed".

7. The method as described in claim 6, characterized in that, The anomaly dimensions and features are input into a pre-trained anomaly attribution inference model to obtain the current anomaly type and the current anomaly cause, including: For any abnormal instance that does not meet the dynamic tolerance strategy, the current abnormal cause of the target business data corresponding to the abnormal instance is determined according to the attribution tree corresponding to the abnormal type of the abnormal instance. The exception type corresponding to the exception instance is determined as the current exception type of the target business data.

8. An anomaly detection device for business data, characterized in that, The device includes: The acquisition unit is used to acquire different business data from different business systems within an enterprise. The association unit is used to perform entity alignment, semantic mapping and association of different business data to obtain different target business data and the association relationship between each target business data. The verification unit is used to perform multi-level matching verification on different target business data based on the correlation between each target business data and a pre-built multi-level verification model to obtain the verification result; wherein, the verification result includes: verification pass status, abnormal dimension and abnormal characteristics. An anomaly analysis unit is used to input the anomaly dimension and anomaly feature into a pre-trained anomaly attribution inference model when the verification pass status is not passed and the anomaly dimension and the anomaly feature do not meet the configured dynamic tolerance strategy, so as to obtain the current anomaly type and the current anomaly cause.

9. An electronic device, characterized in that, The electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images