Bill management method and device, equipment, storage medium and program product
By constructing a multi-level tagging architecture to classify consumer behavior, the problem that existing accounting systems cannot meet the needs of multi-role and multi-scenario consumer analysis is solved, enabling accurate and personalized accounting services and financial product recommendations.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-10
AI Technical Summary
Existing accounting systems cannot meet the needs of in-depth analysis of users' multi-role and multi-scenario consumption behavior in modern financial scenarios, making it difficult to provide users with more accurate and personalized accounting services.
By constructing a multi-level tag architecture (consumption category → consumption scenario → consumption role), paid bills are classified in a multi-dimensional and adaptive manner, generating multi-level tags to label consumption behavior.
It enables precise and personalized management of consumer behavior, supports financial product recommendations and risk control, and improves the accuracy of user profiles and service conversion rates.
Smart Images
Figure CN121836951A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of big data, and in particular, to a bill management method and device, equipment, storage medium and program product. BACKGROUND
[0002] The existing accounting system usually classifies the consumption behavior in a single dimension based on the transaction basic information (such as merchant type code, transaction amount, etc.).
[0003] However, the above classification method cannot meet the demand of modern financial scenarios for deep analysis of user multi-role and multi-scene consumption behavior, resulting in difficulty in providing more accurate and personalized accounting services for users. SUMMARY
[0004] The present application provides a bill management method, device, equipment, storage medium and program product to solve the technical problem that the bill classification method in the related art cannot provide more accurate and personalized accounting services for users.
[0005] In a first aspect, the present application provides a bill management method, comprising:
[0006] obtaining transaction information of a paid bill;
[0007] generating at least one first-level label corresponding to the paid bill according to the transaction information, the first-level label being used to mark the consumption category of the paid bill;
[0008] generating at least one second-level label corresponding to the paid bill according to the at least one first-level label and user historical bills, the second-level label being used to mark the consumption category and consumption scene of the paid bill;
[0009] generating at least one third-level label corresponding to the paid bill according to the at least one second-level label and user portrait data, the third-level label being used to mark the consumption category, consumption scene and consumption role of the paid bill.
[0010] In a second aspect, the present application provides a bill management device, comprising:
[0011] an obtaining module configured to obtain transaction information of a paid bill;
[0012] The processing module is configured to generate at least one first-level label corresponding to the paid bill according to the transaction information, the first-level label being used to mark a consumption category of the paid bill; generate at least one second-level label corresponding to the paid bill according to the at least one first-level label and the historical bill of the user, the second-level label being used to mark the consumption category and a consumption scenario of the paid bill; and generate at least one third-level label corresponding to the paid bill according to the at least one second-level label and the user portrait data, the third-level label being used to mark the consumption category, the consumption scenario and a consumption role of the paid bill.
[0013] In a third aspect, the present application provides an electronic device, comprising: a processor, and a memory connected with the processor in communication;
[0014] The memory stores computer-executable instructions.
[0015] The processor executes the computer-executable instructions stored in the memory to implement the method provided in the first aspect.
[0016] In a fourth aspect, the present application provides a computer-readable storage medium, which stores computer-executable instructions, and the computer-executable instructions are executed by a processor to implement the method provided in the first aspect.
[0017] In a fifth aspect, the present application provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the method provided in the first aspect.
[0018] The bill management method, device, equipment, storage medium and program product provided by the present application can accurately mark the consumption category, consumption scenario and consumption role of the bill by deeply analyzing the transaction information of the paid bill, combining the historical bill of the user and the user portrait data, and generating multi-level labels, thereby providing clearer and personalized bill management services for the user, and providing strong support for financial analysis and consumption planning. BRIEF DESCRIPTION OF DRAWINGS
[0019] The accompanying drawings, which are incorporated into and form a part of the specification, illustrate one embodiment consistent with the present application and, together with the description, serve to explain the principles of the application.
[0020] Figure 1 A flowchart of a bill management method provided in an embodiment of the present application;
[0021] Figure 2 A sub-flowchart of a bill management method provided in an embodiment of the present application Figure 1 ;
[0022] Figure 3 A sub-flowchart of a bill management method provided in an embodiment of the present applicationFigure 2 ;
[0023] Figure 4 A sub-process diagram of a bill management method provided in an embodiment of the present application Figure 3 ;
[0024] Figure 5 A structural diagram of a bill management device provided in an embodiment of the present application
[0025] Figure 6 A structural diagram of an electronic device provided in an embodiment of the present application.
[0026] The specific embodiments of the present application have been shown in the above-described drawings, and will be described in more detail hereinafter. These drawings and the written description are not intended to restrict the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION
[0027] The exemplary embodiments will be described in detail herein with reference to the attached drawings. The same or similar components are denoted by the same reference numerals throughout the drawings and the written description, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not meant to represent all implementations consistent with the present application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the present application as detailed in the appended claims.
[0028] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of related data comply with relevant laws, regulations and standards of relevant countries and regions, necessary security measures are taken, public order and good customs are not violated, and appropriate operation portals are provided for users to choose authorization or refusal.
[0029] And the present application involves big data analysis of user information (including but not limited to personal biological characteristics, identity data, consumption data, asset data, electronic terminal operation data, etc.), and uses artificial intelligence technology for automatic decision-making, and makes technical solutions based on automatic decision-making results that have a significant impact on personal rights and interests, provides appropriate operation portals for users to choose to agree or refuse automatic decision-making results; if the user chooses to refuse, the expert decision-making process is entered.
[0030] It should be noted that the bill management method, device, equipment, storage medium and program product provided in the embodiments of the present application can be used in the field of big data, and can also be used in any field other than big data. The application field of the bill management method, device, equipment, storage medium and program product provided in the embodiments of the present application is not limited.
[0031] In the financial industry, especially in the banking and Internet payment field, the labeling management of user consumption behavior is the core link to realize accurate service and risk control.
[0032] The existing accounting system can usually only classify consumption bills in a single dimension based on basic transaction information (such as merchant category code (MCC), transaction amount, etc.). For example, transactions based on catering merchants are uniformly classified as “catering”, or online shopping transactions are marked as “online shopping” according to MCC, etc.
[0033] However, the above classification method cannot meet the needs of modern financial scenarios for deep insight into user multi-role and multi-scene consumption behavior. For example, the user's car maintenance expenses may involve both “family common expenses” and “personal vehicle use” role dimensions; consumption related to children's education may need to associate the “father role” or “mother role” scene label.
[0034] In addition, financial institutions need to mine user's potential needs through consumption data, such as recommending education financial products to users with “father role” or pushing health management services to users in “family medical expenses” scenario.
[0035] The existing technology cannot realize multi-level mapping of consumption, scene and role through a single label system, resulting in fragmentation of user portraits and lack of accuracy in financial product recommendation. Therefore, there is an urgent need for a bill classification method that can automatically construct multi-level labels to support the needs of fine operation and personalized services in the financial scenario.
[0036] In the face of the above technical problems, the bill management method provided in the embodiments of the present application realizes multi-dimensional and adaptive classification of consumption behavior by constructing a multi-level label architecture (consumption category → consumption scene → consumption role), such as gradually mapping consumption behavior from basic classification (such as “education”, “catering”, etc.) to consumption scene (such as “family expenses”, “children's education”, etc.) and consumption role dimension (such as “father role”), forming a multi-level mapping relationship, and providing more accurate and personalized accounting services for users.
[0037] The technical solutions of the present application and how the technical solutions solve the above technical problems will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes can not be described again in some embodiments. The embodiments of the present application will be described below with reference to the accompanying drawings.
[0038] The bill management method provided in the embodiments of the present application can be applied to the following scenarios:
[0039] Personal financial management: helping individual users better manage their bills, understand their consumption habits and consumption structure, and develop reasonable consumption plans and savings plans.
[0040] Family account management: in a family scenario, the consumption roles and consumption scenarios of each family member are clearly divided through multi-level tags, facilitating the statistics and management of family accounts.
[0041] Enterprise financial analysis: enterprises can use this method to analyze the consumption bills of employees, understand the consumption behavior and expense of employees, and provide basis for expense control and financial decision-making.
[0042] Reference Figure 1 , Figure 1 The flowchart of the bill management method provided in the embodiments of the present application, in some embodiments, the above bill management method comprises:
[0043] S101, acquiring transaction information of a paid bill.
[0044] In some embodiments, the detailed transaction information of the paid bill can be obtained from a payment system, a bank interface or a related financial data platform.
[0045] Optionally, the transaction information can include but is not limited to transaction time, transaction amount, merchant category code, payee account name, transaction location (such as GPS coordinates or address information), etc.
[0046] In some embodiments, a secure data transmission channel can be established with the payment system or the bank interface, and the transaction information can be obtained by using the method of timed pulling or real-time pushing. During data acquisition, the integrity and accuracy of the data need to be ensured, for example, the data can be preliminarily cleaned and verified to remove duplicate, incorrect or incomplete data records.
[0047] S102, generating at least one first-level tag corresponding to the paid bill according to the transaction information, the first-level tag being used to mark the consumption category of the paid bill.
[0048] In some embodiments, the payee account name is semantically analyzed using natural language processing (NLP) techniques. For example, "XX supermarket" is analyzed as "shopping", "XX hospital" is analyzed as "medical treatment", and the like, to preliminarily determine the consumption category to which the transaction belongs from the semantic level.
[0049] In some embodiments, the consumption category to which the transaction belongs can be further determined according to the merchant category code (MCC).
[0050] The MCC is an internationally recognized merchant industry classification code, and different MCCs correspond to different consumption categories. For example, MCC = 812 corresponds to "dining", MCC = 8299 corresponds to "education", and the like. According to the MCC, the consumption category of the transaction can be further determined.
[0051] After determining the consumption category corresponding to the paid bill, at least one first-level label corresponding to the paid bill can be generated according to the consumption category corresponding to the paid bill.
[0052] S103, according to at least one first-level label, and user historical bills, generate at least one second-level label corresponding to the paid bill, which is used to mark the consumption category and consumption scene of the paid bill.
[0053] In some embodiments, the first-level label of the current paid bill can be aggregated and analyzed with the user historical bills. The consumption frequency, consumption amount, consumption time distribution and the like of the user under the same or similar first-level label are counted to mine the consumption habits and patterns of the user.
[0054] The clustered data is analyzed using a clustering algorithm. Transactions with similar consumption characteristics (such as the same first-level label, similar transaction location, high-frequency consumption combination, etc.) are clustered into the same consumption scene in combination with transaction location information. For example, "education" class consumption occurring multiple times at the same school location is clustered into the "children's education" scene, and "shopping" class consumption occurring multiple times at the same mall is clustered into the "mall shopping" scene, and the like.
[0055] According to the clustering result, a second-level label is generated to mark the consumption category and consumption scene of the paid bill. The second-level label further refines the first-level label to more accurately describe the specific scene of the consumption.
[0056] S104, according to at least one second-level label, and user portrait data, generate at least one third-level label corresponding to the paid bill, which is used to mark the consumption category, consumption scene and consumption role of the paid bill.
[0057] In some embodiments, basic information (such as age, gender, occupation, etc.), family structure information (such as family member composition, relationship, etc.), consumption preference information (such as favorite brands, consumption frequency, etc.), and the like of the user can be collected to construct user portrait data.
[0058] Optionally, the user portrait data can be obtained through active filling by the user, data analysis and mining, and the like.
[0059] In some embodiments, the secondary label is matched with a role definition in the user portrait. According to the consumption behavior characteristics corresponding to different roles (such as father, mother, child, and the like) defined in the user portrait, the consumption role corresponding to the paid bill is determined.
[0060] For example, if the "father" role in the user portrait is defined to be responsible for child education and medical consumption, when the secondary label is "child education", it can be determined that the consumption role of the bill is "father".
[0061] In some embodiments, the secondary label and the role matching result are integrated to generate a tertiary label, which is used to label the consumption category, consumption scenario, and consumption role of the paid bill.
[0062] The tertiary label is the most fine-grained label, which can comprehensively and accurately describe the consumption information of the bill.
[0063] The bill management method provided in the embodiments of the present application can generate multi-level labels by deep analysis of the transaction information of the paid bill, in combination with the user historical bill and user portrait data, so as to accurately label the consumption category, consumption scenario, and consumption role of the bill, provide clearer and more personalized bill management services for the user, and also provide strong support for financial analysis and consumption planning.
[0064] Reference Figure 2 , Figure 2 FIG. 1 is a flowchart of a bill management method provided in an embodiment of the present application Figure 1 In some embodiments, the above generating at least one primary label corresponding to the paid bill according to the transaction information comprises:
[0065] S201, the semantic information in the payee account name is analyzed to determine the first category label.
[0066] In some embodiments, the payee account name can be input as input text into a pre-trained language model, such as a BERT (Bidirectional Encoder Representations from Transformers) model. The BERT model will encode the input text and convert it into high-dimensional vector representations that contain the semantic features of the text. Then, a classification layer (such as a fully connected layer) is used to classify these vectors and map the payee account name to a predefined consumption category. For example, "XX International School" is parsed as the "education" category, and "XX Restaurant" is parsed as the "dining" category.
[0067] For some payee account names, there may be ambiguity, such as "XX Garden", which may be a residential complex or a dining place (such as a garden restaurant). For such cases, other transaction information (such as transaction location, transaction amount, etc.) can be combined for comprehensive judgment. If the transaction location is in a commercial area and the transaction amount meets the characteristics of dining consumption, it is more inclined to be classified as the "dining" category.
[0068] S202, match the merchant category code with the pre-set classification table to determine the second category label.
[0069] In some embodiments, a detailed pre-set classification table can be pre-constructed to map all MCC codes to their corresponding consumption categories.
[0070] Optionally, the above classification table can be customized and updated according to industry standards or actual needs.
[0071] In some embodiments, the merchant category code can be extracted from the transaction information, and then the corresponding consumption category can be found in the pre-set classification table to determine the second category label.
[0072] For example, if the merchant category code in the transaction information is 5411, the corresponding consumption category "shopping-supermarket" can be found in the pre-set classification table, so the second category label can be determined as "shopping-supermarket".
[0073] S203, generate at least one primary label corresponding to the paid bill according to the first category label and the second category label.
[0074] In some embodiments, the first category label and the second category label can be fused by weighted fusion or rule fusion to generate the final primary label.
[0075] The weighted fusion can assign different weights according to the confidence or importance of the two labels, and the rule fusion can formulate a series of rules to determine the final label. For example, if the first category label and the second category label are consistent, the label is directly adopted as the primary label; if they are inconsistent, a preset rule is used for judgment, such as preferentially adopting the semantic parsing result or comprehensively deciding by combining other transaction information.
[0076] In some embodiments, one paid bill can involve multiple consumption categories, and therefore multiple primary labels can be generated. For example, a consumption bill of a restaurant in a mall can be labeled as both the "dining" category and the "shopping-mall" category.
[0077] For example, if the first category label is "education-training" and the second category label is "service-training", according to the rule fusion strategy, the final primary label is determined to be "education-training". If a transaction involves both buying books in a bookstore (the first category label is "shopping-books") and consuming in a coffee shop in the bookstore (the second category label is "dining-coffee shop"), two primary labels "shopping-books" and "dining-coffee shop" can be generated.
[0078] Through the above embodiments, at least one primary label corresponding to the paid bill can be accurately and comprehensively generated, providing a solid foundation for subsequent bill management and analysis.
[0079] Reference Figure 3 , Figure 3 A sub-process diagram of a bill management method provided in an embodiment of the present application Figure 2 In some embodiments, the above generating at least one secondary label corresponding to the paid bill according to the at least one primary label and the user historical bills comprises:
[0080] S301, clustering the paid bill and the user historical bills according to the primary label and the transaction location information.
[0081] In some embodiments, the primary label and the transaction location information can be used as features to describe each bill. The primary label reflects the category of consumption, and the transaction location information (such as GPS coordinates or a specific address) provides the location information of the consumption. By combining the information of these two dimensions, the characteristics of each bill can be more comprehensively described.
[0082] In some embodiments, a suitable similarity calculation method can be employed to measure the similarity between different bills. For transaction location information, if GPS coordinates are used, Euclidean distance can be employed to calculate the spatial distance between two locations; if specific addresses are used, the addresses can be first encoded (e.g., converted into latitude and longitude coordinates using geocoding techniques) and then distance calculation can be performed. For primary labels, cosine similarity or other methods can be employed to measure the semantic similarity between labels. By integrating spatial distance and label similarity, the comprehensive similarity between two bills can be calculated.
[0083] In some embodiments, paid bills and user historical bills can be collected, and the primary labels and transaction location information of each bill can be extracted. The transaction location information can be preprocessed, such as converting addresses into latitude and longitude coordinates (if not already converted).
[0084] Further, the primary labels can be encoded (e.g., using one-hot encoding or word embedding encoding) and combined with the transaction location information (latitude and longitude coordinates) into a feature vector.
[0085] Further, according to the selected similarity calculation method and clustering algorithm, the similarity between bills can be calculated and clustering can be performed.
[0086] For example, using the Density-Based Spatial Clustering of Applications with Noise (DBSCAN) algorithm with noise, a suitable neighborhood radius and minimum sample size can be set to cluster bills with high similarity into a class.
[0087] The DBSCAN algorithm can discover clusters of arbitrary shape and does not require the number of clusters to be specified in advance.
[0088] S302, according to the clustering result, at least one secondary label corresponding to the paid bill is generated.
[0089] Each cluster represents a consumption scenario with similar characteristics. By analyzing the bills in the cluster, the common characteristics of the scenario can be mined, and thus the secondary label can be determined. For example, if the primary labels of the bills in a cluster are all "dining" and the transaction locations are all concentrated in a mall, the consumption scenario corresponding to the cluster can be determined to be "mall dining", and the secondary label "mall dining" can be generated.
[0090] In some embodiments, detailed analysis can be performed on the bills in each cluster, and the distribution of primary labels and the concentration of transaction locations can be counted. For example, the frequency of different primary labels in the cluster can be calculated to find the main primary label, and the distribution range of the transaction location can be analyzed to determine the location characteristics.
[0091] According to the results of the cluster analysis, the secondary tags are generated according to the tag naming rules. For example, for a primary tag of "shopping", a cluster of transaction locations is concentrated in a supermarket, and a secondary tag of "supermarket shopping" is generated; for a primary tag of "entertainment", a cluster of transaction locations is concentrated near a cinema, and a secondary tag of "cinema entertainment" is generated.
[0092] According to the above embodiments, the consumption scenarios corresponding to the paid bills can be accurately analyzed according to the primary tags and transaction location information, and then the secondary tags are generated, providing a basis for subsequent bill management and analysis.
[0093] Referring to Figure 4 , Figure 4 Figure 1 is a flowchart of a bill management method according to an embodiment of the present application Figure 3 In some embodiments, the above generating at least one tertiary tag corresponding to the paid bill according to at least one secondary tag and user portrait data comprises:
[0094] S401, extracting at least one target role according to role definition information in the user portrait data.
[0095] The role definition information in the user portrait data can be stored in a structured or semi-structured form, such as fields in a database table, JSON format data, etc. By parsing these data, the role information of the user can be extracted. For example, if the user portrait data contains "occupation", "family role", "consumption role" and other fields, the role information of the user in different dimensions can be extracted therefrom.
[0096] In some embodiments, the extracted role information is classified and filtered according to the business requirements and the standards of role definition. For example, the family role can be divided into "father", "mother", "child" and the like. Through filtering, the target role related to the current bill analysis is determined.
[0097] For example, the role definition information of the user can be obtained from the user portrait database or related data storage system; at least one target role is extracted from the above role definition information according to a preset role classification rule and business requirement.
[0098] S402, generating at least one tertiary tag corresponding to the paid bill according to at least one target role and at least one secondary tag.
[0099] In some embodiments, correlation analysis can be performed on each target role and secondary label to determine their logical relationship and consumption scenarios. For example, by analyzing historical data, the consumption frequency, consumption amount, and other indicators of different roles under different secondary labels are counted to find out the role and secondary label combination with significant correlation.
[0100] According to the results of the correlation analysis and the label naming rules, the third-level label corresponding to the paid bill is generated. For example, for the target role "parent" and the secondary label "children education-training", the third-level label "parent-children education training" is generated.
[0101] In some embodiments, the generated multiple third-level labels can be optimized and verified to ensure the accuracy and reasonableness of the labels. The labels can be verified through manual review, user feedback, and other means, and the labels can be adjusted and improved according to the verification results.
[0102] Through the above embodiments, the bill can be classified more carefully by combining the role information in the user portrait with the secondary label, and the consumption of a specific group in a specific scenario can be more accurately located.
[0103] In some embodiments, the above method of generating at least one third-level label corresponding to the paid bill according to at least one target role and at least one secondary label comprises:
[0104] Obtaining historical consumption data of at least one target role; determining the weight distribution ratio of at least one target role with respect to at least one secondary label according to the historical consumption data of at least one target role; and generating at least one third-level label corresponding to the paid bill according to the weight distribution ratio of at least one target role with respect to at least one secondary label.
[0105] In some embodiments, the weight distribution algorithm formula is:
[0106] ;
[0107] where k represents the weight of the target role with respect to a certain secondary label, s represents the cumulative consumption amount of the target role in the same or similar consumption scenario in the past period of time, for example, in the car maintenance fee scenario, it is the total consumption of the target role in the past car maintenance; b represents the total consumption amount in the entire consumption scenario, for example, in the car maintenance fee scenario, it is the total sum of all consumption amounts related to car maintenance; and c represents a position correction coefficient, which is introduced to adjust the weight considering that different geographical locations, consumption places, and other factors may have an impact on consumption behavior.
[0108] For example, assume that the historical consumption of the family role in car maintenance in the past year is 6000 yuan, the historical consumption of the individual role is 4000 yuan, and the total consumption of the scene is 10000 yuan. Assuming that the location correction coefficient is 1 (not considering the influence of location factors), the weight of the family role is 60%, and the weight of the individual role is 40%. The generated three-level label can be "family-transportation-travel-car maintenance (60%), individual-transportation-travel-car maintenance (40%)".
[0109] Through the above embodiments, reasonable weights can be allocated to different roles to more accurately reflect the contribution or correlation degree of each role in the current consumption scene.
[0110] In some embodiments, the above method further comprises:
[0111] Abnormal detection is performed on at least one three-level label, and the three-level label with an abnormality is pushed to the user display interface. According to the received user operation, the three-level label with an abnormality is modified.
[0112] In some embodiments, the above abnormal detection comprises:
[0113] I. Statistical analysis based on historical data
[0114] The mean and standard deviation of the historical consumption amount corresponding to each three-level label are calculated. A threshold range is set. If the consumption amount of the current three-level label exceeds this threshold range, it is determined to be abnormal.
[0115] II. Detection based on business rules
[0116] Check whether the consumption corresponding to the three-level label conforms to the business scene represented by the label. For example, if the consumption amount corresponding to the "individual-transportation-travel-fueling" label is too large, there may be a label classification error or data anomaly.
[0117] Alternatively, according to business experience, a reasonable consumption frequency range for each three-level label is set. If the consumption frequency exceeds this range, it is determined to be abnormal. For example, family car maintenance usually has a certain period (such as once every six months), and if multiple maintenance consumption records appear within a short period of time, there may be an anomaly.
[0118] When there is an abnormal three-level label, the user can be notified of the three-level label with an abnormality through application push notifications. The notification content can include the name of the abnormal label, the consumption amount, the consumption time, and other key information.
[0119] If the user believes that the three-level label is misclassified, the correct three-level label can be selected according to the actual situation. According to the user's operation, the classification information and consumption records of the three-level label can be updated in a timely manner.
[0120] Through the above-mentioned embodiments, through the exception detection and user feedback mechanism, errors in the data can be discovered and corrected in time, improving the accuracy of three-level label classification and consumption records, and providing more reliable data support for subsequent financial management and consumption analysis.
[0121] The bill management method provided in the embodiments of the present application can achieve the following beneficial effects:
[0122] The hierarchical mapping capability of consumption, scene, and role is realized, so that the user can view fine data such as the proportion of expenditure of the father role, and support for financial product recommendation and risk control.
[0123] Through the combination of historical consumption amount and position correction coefficient, the multi-role consumption allocation problem (such as the purchase of a car is divided into “family expenses 60%”+ “personal expenses 40%”) is solved.
[0124] Based on the role dimension label (such as “father role-education expenses”), the financial product recommendation can significantly improve the matching degree of user demand and the service conversion rate.
[0125] The scheme breaks through the limitation of single dimension classification of traditional systems, and provides high-precision and high-generalization bill classification and user portrait construction capability for the financial industry.
[0126] The embodiments of the present application also provide a bill management device, as shown in Figure 5 The structure schematic diagram of a bill management device provided in the embodiments of the present application is shown in Figure 5 The bill management device 50 includes:
[0127] The acquisition module 501 is configured to acquire transaction information of a paid bill.
[0128] The processing module 502 is configured to generate at least one first-level label corresponding to the paid bill according to the transaction information, the first-level label being used to mark a consumption category of the paid bill; generate at least one second-level label corresponding to the paid bill according to the at least one first-level label and user historical bills, the second-level label being used to mark a consumption category and a consumption scene of the paid bill; and generate at least one third-level label corresponding to the paid bill according to the at least one second-level label and user portrait data, the third-level label being used to mark the consumption category, the consumption scene, and a consumption role of the paid bill.
[0129] In some embodiments, the transaction information includes a merchant category code and a payee account name; and the processing module 502 is configured to:
[0130] analyze semantic information in the payee account name to determine a first category label;
[0131] The merchant category code is matched with a preset classification table to determine a second category label.
[0132] According to the first category label and the second category label, at least one primary label corresponding to the paid bill is generated.
[0133] In some embodiments, the transaction information includes transaction location information; the processing module 502 is configured to:
[0134] According to the primary label and the transaction location information, the paid bill and the user historical bills are clustered;
[0135] According to the clustering result, at least one secondary label corresponding to the paid bill is generated.
[0136] In some embodiments, the processing module 502 is configured to:
[0137] According to the role definition information in the user portrait data, at least one target role is extracted;
[0138] According to the at least one target role and the at least one secondary label, at least one tertiary label corresponding to the paid bill is generated.
[0139] In some embodiments, the processing module 502 is configured to:
[0140] Obtain historical consumption data of the at least one target role;
[0141] According to the historical consumption data of the at least one target role, a weight distribution ratio of the at least one target role with respect to the at least one secondary label is determined;
[0142] According to the weight distribution ratio of the at least one target role with respect to the at least one secondary label, at least one tertiary label corresponding to the paid bill is generated.
[0143] In some embodiments, the processing module 502 is further configured to:
[0144] Abnormality detection is performed on the at least one tertiary label;
[0145] The tertiary label with an abnormality is pushed to a user display interface;
[0146] According to the received user operation, the tertiary label with an abnormality is modified.
[0147] The bill management device provided by the embodiments of the present application can execute the bill management method provided by the above-mentioned method embodiments, and the implementation principles and technical effects are similar, and the present embodiment will not be repeated here.
[0148] Figure 6 A structural schematic diagram of an electronic device provided in the embodiments of the present application is shown in FIG. 1.Figure 6 As shown, the electronic device 60 provided by the embodiment includes at least one processor 601 and a memory 602. Optionally, the electronic device 60 further includes a communication component 603. The processor 601, the memory 602 and the communication component 603 are connected through a bus.
[0149] In the implementation process, the at least one processor 601 executes the computer execution instructions stored in the memory 602, so that the at least one processor 601 executes the bill management method provided by the above-mentioned embodiment.
[0150] The specific implementation process of the processor 601 can refer to the method embodiments described above, which has similar implementation principles and technical effects. Therefore, the specific implementation process of the processor 601 will not be described here again.
[0151] In the above-mentioned embodiments, the processor can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the present application can be directly embodied by a hardware processor for execution, or by a combination of hardware and software modules in the processor for execution.
[0152] The memory can include a random access memory (RAM), and can also include a non-volatile memory (NVM), such as at least one disk memory.
[0153] The bus can be an industry standard architecture (ISA) bus, a peripheral component (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, the bus in the drawings of the present application does not limit to only one bus or one type of bus.
[0154] The present application also provides a computer program product, including a computer program, which is executed by a processor to implement the bill management method provided by the above-mentioned embodiment.
[0155] The application further provides a computer readable storage medium, and the computer readable storage medium stores computer execution instructions.
[0156] The readable storage medium can be realized by any type of volatile or nonvolatile storage devices or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.
[0157] An exemplary readable storage medium is coupled to the processor, so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist as discrete components in the device.
[0158] The division of units is only a logical function division, and in actual implementation, there can be another division mode, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or components shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0159] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. According to actual needs, part or all of the units can be selected to achieve the purpose of the embodiment.
[0160] In addition, the functional units in each embodiment of the application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit.
[0161] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.
[0162] Those of ordinary skill in the art can understand that all or part of the steps of the above-mentioned method embodiments can be completed by program instruction-related hardware. The aforementioned program can be stored in a computer readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: a ROM, a RAM, a magnetic disk or an optical disk, and various media that can store program codes.
[0163] Finally, it should be noted that: those skilled in the art will easily derive other embodiments of the present application after considering the specification and practicing the disclosed content. The present application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common knowledge or conventional technical means in the art that are not disclosed in the present application, and is not limited to the precise structures described above and shown in the drawings, and various modifications and changes can be made without departing from the scope thereof. The scope of the present application is only limited by the appended claims.
Claims
1. A billing management method, characterized in that, The method includes: Retrieve transaction information for paid bills; Based on the transaction information, at least one primary tag is generated corresponding to the paid bill, and the primary tag is used to mark the consumption category of the paid bill; Based on the at least one primary tag and the user's historical bills, generate at least one secondary tag corresponding to the paid bill. The secondary tag is used to mark the consumption category and consumption scenario of the paid bill. Based on the at least one secondary tag and user profile data, at least one tertiary tag is generated corresponding to the paid bill. The tertiary tag is used to mark the consumption category, consumption scenario and consumption role of the paid bill.
2. The method according to claim 1, characterized in that, The transaction information includes a merchant category code and a receiving account name; the step of generating at least one primary tag corresponding to the paid bill based on the transaction information includes: The semantic information in the name of the receiving account is parsed to determine the first category label; The merchant category code is matched with a preset category table to determine the second category label; Based on the first category label and the second category label, at least one primary label corresponding to the paid bill is generated.
3. The method according to claim 1, characterized in that, The transaction information includes transaction location information; The step of generating at least one secondary tag corresponding to the paid bill based on the at least one primary tag and the user's historical bills includes: Based on the primary tags and the transaction location information, the paid bills and the user's historical bills are clustered. Based on the clustering results, at least one secondary label is generated corresponding to the paid bill.
4. The method according to claim 1, characterized in that, The step of generating at least one tertiary tag corresponding to the paid bill based on the at least one secondary tag and user profile data includes: Based on the role definition information in the user profile data, extract at least one target role; Based on the at least one target role and the at least one secondary tag, generate at least one tertiary tag corresponding to the paid bill.
5. The method according to claim 4, characterized in that, The step of generating at least one tertiary tag corresponding to the paid bill based on the at least one target role and the at least one secondary tag includes: Obtain historical consumption data of at least one target character; Based on the historical consumption data of the at least one target character, determine the weight allocation ratio of the at least one target character relative to the at least one secondary tag; Based on the weight allocation ratio of the at least one target role relative to the at least one secondary tag, at least one tertiary tag corresponding to the paid bill is generated.
6. The method according to claim 1, characterized in that, The method further includes: Anomaly detection is performed on at least one level 3 label; Push the abnormal level 3 tags to the user's display interface; Based on the received user action, modify the abnormal level 3 tag.
7. A billing management device, characterized in that, include: The acquisition module is used to retrieve transaction information for paid bills; The processing module is configured to generate at least one primary tag corresponding to the paid bill based on the transaction information, wherein the primary tag is used to label the consumption category of the paid bill; generate at least one secondary tag corresponding to the paid bill based on the at least one primary tag and the user's historical bills, wherein the secondary tag is used to label the consumption category and consumption scenario of the paid bill; and generate at least one tertiary tag corresponding to the paid bill based on the at least one secondary tag and user profile data, wherein the tertiary tag is used to label the consumption category, consumption scenario, and consumption role of the paid bill.
8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.