Account hanging processing method and device, equipment, medium and program product
By automatically analyzing outstanding account inspection emails using RPA technology, and combining risk prediction and fake outstanding account identification models, the high cost and inefficiency caused by the reliance on manual handling in existing technologies are solved, achieving automated, accurate and efficient outstanding account processing.
Patent Information
- Application Number
- CN202511229712.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-29
- Publication Date
- 2025-12-12
AI Technical Summary
In existing technologies, the processing of outstanding accounts requires complete reliance on technical personnel for analysis, resulting in high costs and low efficiency.
By using Robotic Process Automation (RPA) technology to obtain emails for checking outstanding accounts, the system automatically identifies the email type and determines the details of outstanding accounts and bad debt risks. Using pre-built risk prediction models and fake outstanding account identification models, the system automatically distributes processing tasks, reducing human intervention.
It reduced the cost of handling outstanding accounts, improved processing efficiency, reduced manpower and analysis cycle, and improved the accuracy and efficiency of processing.
Smart Images
Figure CN121120279A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of financial technology, and in particular to a method, apparatus, equipment, medium, and program product for processing outstanding accounts. Background Technology
[0002] In the fields of corporate financial management, financial credit, and commercial transactions, deferred accounts are a common accounting practice. Its core is to temporarily record economic transactions that have not yet been settled in a specific account, and then process them after the settlement conditions are met.
[0003] In existing technologies, outstanding accounts receivable for a target object are typically presented in tabular form to technical personnel. After the technical personnel analyze the outstanding accounts in the tabular form, the analysis results are then fed back to the object to be processed. However, existing technologies rely entirely on technical personnel for outstanding account analysis, resulting in high costs and low efficiency in outstanding account processing. Summary of the Invention
[0004] This invention provides a method, apparatus, equipment, medium, and program product for processing outstanding accounts, which reduces the cost and improves the efficiency of outstanding account processing.
[0005] In a first aspect, embodiments of the present invention provide a method for handling outstanding accounts, including:
[0006] Retrieve each outstanding payment check email corresponding to the target object, and determine the email type of each outstanding payment check email based on its subject line.
[0007] Emails with the type "active posting" for posting inspection are treated as active posting emails. Based on the active posting emails, each active posting corresponding to the target object is identified, along with the posting details for each active posting.
[0008] Based on the detailed information of each proactive type of receivable, determine the bad debt risk and receivable processing object corresponding to each proactive type of receivable;
[0009] Send the detailed information of each proactively accrued account and its bad debt risk to the corresponding account processing object.
[0010] Secondly, embodiments of the present invention also provide an account receivable processing device, comprising:
[0011] The email type determination module is used to obtain each outstanding payment inspection email corresponding to the target object, and determine the email type of each outstanding payment inspection email based on the email subject of each outstanding payment inspection email.
[0012] The receivables details determination module is used to treat receivables check emails of the receivables type as receivables emails, and based on the receivables emails, determine each receivable of the receivables type corresponding to the target object, as well as the receivables details information of each receivable of the receivables type.
[0013] The outstanding accounts analysis module is used to determine the bad debt risk and outstanding accounts processing object corresponding to each active type of outstanding account based on the outstanding account details information.
[0014] The deferred payment processing module is used to send the deferred payment details and bad debt risk of each actively deferred payment to the corresponding deferred payment processing object.
[0015] Thirdly, embodiments of the present invention also provide an electronic device, the electronic device comprising:
[0016] At least one processor; and
[0017] A memory that is communicatively connected to at least one processor; wherein,
[0018] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to perform the account processing method provided in any embodiment of the present invention.
[0019] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the account receivable processing method provided in any embodiment of the present invention.
[0020] Fifthly, embodiments of the present invention also provide a computer program product, which includes a computer program that, when executed by a processor, implements the account receivable processing method provided in any embodiment of the present invention.
[0021] The technical solution of this invention, through proactive posting emails, identifies each proactive posting type corresponding to a target object, along with the posting details for each proactive posting type. Based on the posting details corresponding to each proactive posting type, it determines the bad debt risk and posting processing object corresponding to each proactive posting type. The posting details and bad debt risk for each proactive posting type are then sent to the corresponding posting processing object. This approach solves the problem of existing technologies that rely entirely on technical personnel for posting analysis, resulting in low posting processing efficiency. It avoids the need for significant manpower for similar analysis work with large timeframes, thereby reducing posting processing costs and improving posting processing efficiency.
[0022] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description
[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0024] Figure 1 This is a flowchart of an account receivable processing method provided in Embodiment 1 of the present invention;
[0025] Figure 2 This is a flowchart of another method for handling outstanding accounts according to Embodiment 2 of the present invention;
[0026] Figure 3 This is a schematic diagram of the structure of an account receivable processing device according to Embodiment 3 of the present invention;
[0027] Figure 4 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. Detailed Implementation
[0028] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0030] Example 1
[0031] Figure 1 This is a flowchart of an account receivable processing method according to Embodiment 1 of the present invention. This embodiment is applicable to the processing of account receivables. The method can be executed by an account receivable processing device, which can be implemented in hardware and / or software and can be configured in an electronic device such as a computer.
[0032] like Figure 1 As shown in this embodiment, a method for processing outstanding accounts includes:
[0033] S110. Obtain each outstanding payment check email corresponding to the target object, and determine the email type of each outstanding payment check email based on the email subject of each outstanding payment check email.
[0034] In this embodiment, the target object can be understood as an object with outstanding accounts, such as banks and individual businesses. An outstanding account check email can be understood as an email used to reflect the type and details of the outstanding accounts.
[0035] In this step, specifically, Robotic Process Automation (RPA) technology can be used to first execute the following RPA logic: Technicians search daily for outstanding payment check emails corresponding to the target object based on the email subject, and determine the email type of each outstanding payment check email based on its subject. Then, based on this first execution logic, each outstanding payment check email corresponding to the target object can be retrieved, and the email type can be obtained from the email subject. The email type can include both proactive and reactive outstanding payments.
[0036] S120. Treat the posting inspection email with the email type of "active posting" as an active posting email, and based on the active posting email, determine each active posting corresponding to the target object, as well as the posting details of each active posting.
[0037] In this embodiment, the proactive posting email can be used to reflect the posting details of proactive postings corresponding to the target object. Proactive postings can be understood as postings initiated proactively within the target object. The posting details of proactive postings may include the posting date, the application involved, the business number, the transaction code, the account number, the medium number, the reason for the proactive posting, the lending direction, the amount in local currency, and the currency.
[0038] In this step, specifically, RPA technology can be used to write the second execution logic of the RPA, which involves technicians identifying proactively postponed expense emails based on email type, determining each proactively postponed expense corresponding to the target object, and the expense details for each proactively postponed expense. Then, based on this second execution logic, expense check emails of the proactively postponed expense type can be treated as proactively postponed expense emails, and the proactively postponed expense corresponding to the target object, along with its detailed expense information, can be retrieved from these emails.
[0039] S130. Based on the detailed information of each active type of outstanding account, determine the bad debt risk and the outstanding account handling object corresponding to each active type of outstanding account.
[0040] In this step, specifically, RPA technology can be used to write the third execution logic of the RPA, which involves technicians determining the bad debt risk and the corresponding handling object for each proactive type of outstanding debt based on the outstanding debt details. Then, based on the third execution logic, the bad debt risk and the handling object corresponding to each proactive type of outstanding debt can be determined.
[0041] In one specific implementation, the bad debt risk of proactively postponed accounts can be determined by at least one of the following: posting date, involved application, account, medium number, reason for proactive posting, lending direction, amount in local currency, and currency. The posting processing object of proactively postponed accounts can be determined by at least one of the following: involved application and transaction code.
[0042] S140. Send the detailed information of each active type of outstanding account and the bad debt risk to the corresponding outstanding account processing object.
[0043] In this step, specifically, a pre-built solution generation model can be used to determine the corresponding handling plan for each proactive type of outstanding debt based on the outstanding debt details and bad debt risk associated with each debt. Then, the outstanding debt details, bad debt risk, and handling plan for each proactive type of outstanding debt can be sent to the corresponding outstanding debt handling recipient via email or other means, while simultaneously tracking the processing progress of the outstanding debt handling recipient.
[0044] Alternatively, Business Intelligence (BI) analytics can be used to determine the appropriate handling plan for each proactive type of outstanding debt based on the outstanding debt details and bad debt risk associated with each debt. A visual BI dashboard can then be used to display the outstanding debt details, bad debt risk, and handling plan to the relevant debt handling parties, allowing them to intuitively obtain the relevant outstanding debt details, bad debt risk, and handling plan.
[0045] The technical solution of this embodiment solves the problem of low efficiency in the prior art, which requires technical personnel to perform account receivable analysis, by acquiring each account receivable check email corresponding to the target object and determining the email type of each account receivable check email based on its subject; classifying account receivable check emails of the type "proactive account receivable" as proactive account receivable emails; determining each proactive account receivable and its detailed information based on the proactive account receivable emails; determining the bad debt risk and the account receivable processing object corresponding to each proactive account receivable based on the detailed information of each proactive account receivable; and sending the detailed information of each proactive account receivable and its bad debt risk to the corresponding account receivable processing object. This approach reduces the cost of account receivable processing and improves its efficiency.
[0046] Example 2
[0047] Figure 2 This is a flowchart of another method for handling outstanding accounts according to Embodiment 2 of the present invention. This embodiment is a further optimization and extension based on the above embodiments and can be combined with various optional technical solutions in the above embodiments.
[0048] like Figure 2 As shown in this embodiment, a method for processing outstanding accounts includes:
[0049] S210. Obtain each outstanding payment check email corresponding to the target object, and determine the email type of each outstanding payment check email based on the email subject of each outstanding payment check email.
[0050] S220. Treat the posting inspection email with the email type of "active posting" as an active posting email, and determine each active posting corresponding to the target object, as well as the posting details of each active posting, based on the active posting email; wherein, the posting details of active posting may include the posting date, posting reason and transaction type.
[0051] S230. Using a pre-built risk prediction model, determine the bad debt risk of each proactive type of outstanding debt based on the outstanding debt date and reason corresponding to each outstanding debt.
[0052] In one specific implementation, the duration of each proactively accrued account can be determined based on the accrual date and the current time. Then, the accrual duration and reason for each proactively accrued account can be input into a pre-built risk prediction model for processing to obtain the bad debt risk for each proactively accrued account.
[0053] In another specific implementation, if the details of proactively outstanding accounts also include the account, the number of times the reason for each proactively outstanding account is raised by the same account within a set period can be determined based on the reason for the outstanding account and the account corresponding to each proactively outstanding account. Then, the bad debt risk of each proactively outstanding account can be determined using a pre-built risk prediction model, based on the outstanding account duration corresponding to each proactively outstanding account and the number of times the reason for the outstanding account is raised by the same account within the set period.
[0054] S240. Based on the transaction code corresponding to each active type of posting, determine the posting processing object corresponding to each active type of posting.
[0055] In one specific implementation, the department to which the transaction code belongs can be determined based on the meaning of each character in the transaction code. Then, the corresponding account processing object for each proactive account can be determined based on the department to which the transaction code belongs.
[0056] The advantage of this setup is that, compared to methods that determine bad debt risk based on at least one of the following: outstanding date, involved application, account, medium number, reason for proactive outstandingment, lending direction, amount in local currency, and currency type, the technical solution in this embodiment determines the bad debt risk of each proactive outstanding debt by specifying the outstanding date and reason corresponding to each outstanding debt. This improves the efficiency of bad debt risk prediction while ensuring its accuracy. Secondly, compared to the method where outstanding debt processing objects self-claim their processing tasks, the technical solution in this embodiment determines the outstanding debt processing object through transaction codes, improving the efficiency of task distribution and thus increasing overall outstanding debt processing efficiency, avoiding business risks arising from untimely processing of outstanding debts.
[0057] Optionally, based on the transaction code corresponding to each active type of posting, determine the posting processing object corresponding to each active type of posting, including: based on the transaction code corresponding to each active type of posting and a predefined posting processing object table, determine the posting processing object corresponding to each active type of posting; wherein, the posting processing object table contains the correspondence between transaction codes and posting processing objects.
[0058] Specifically, the predefined posting processing object table can be queried based on the transaction code corresponding to each active posting to obtain the posting processing object corresponding to each active posting.
[0059] The advantage of this setup is that by using the transaction code corresponding to each active type of posting and a predefined posting processing object table, the posting processing object corresponding to each active type of posting can be determined, thus improving the efficiency and accuracy of determining the posting processing object.
[0060] S250. Send the detailed information of each active type of outstanding account and the bad debt risk to the corresponding outstanding account processing object.
[0061] S260. Treat the posting inspection emails with the email type of passive posting as passive posting emails, and based on the passive posting emails, determine each passive posting corresponding to the target object, as well as the posting details of each passive posting.
[0062] In this embodiment, passive type of outstanding debt can be understood as an outstanding debt initiated actively by an external party to the target object. The outstanding debt details of passive type outstanding debt may include the outstanding debt date, interest accrual date, application involved, business number, transaction code, account number, lending direction, amount in local currency, currency type, region code, and branch number, etc.
[0063] S270. Using a pre-built fake account recognition model, based on a pre-defined account splitting and merging table and the account details corresponding to each passive type account, determine whether each passive type account is a fake account caused by the merging of accounts or a fake account caused by inconsistent business numbers.
[0064] In this embodiment, the fake account recognition model can be a random forest model. The account splitting and merging table includes records of account splitting and merging. Fake accounts caused by merging can be understood as fake accounts that combine multiple transactions into one for recording. Fake accounts caused by inconsistent business numbers can be understood as passive type accounts where all account details are the same except for the business number.
[0065] In this step, specifically, because current accounting day-end batch processing performs debit and credit balance checks based on account affiliation, accounting branch, currency, or system business number, passive suspense is generated when there is a one-sided imbalance. Therefore, false suspense often occurs when different system business numbers are used for the debit and credit sides of a transaction, different branch numbers are registered for the transaction, the accounting end flag is not submitted, or the day-end batch posting is not triggered. The technical solution of this embodiment analyzes various situations that generate false suspense and identifies two types of false suspense: inconsistent system business numbers of the debit and credit side details of the transaction, and transactions involving consolidation processing.
[0066] Furthermore, in order to identify these two types of false outstanding accounts, the outstanding account splitting and merging table, as well as the outstanding account details corresponding to each passive type outstanding account, can be input into a pre-built false outstanding account identification model for processing to determine whether each passive type outstanding account is a false outstanding account caused by the merging of transactions or a false outstanding account caused by inconsistent business numbers.
[0067] Optionally, using a pre-built fake account recognition model, based on a pre-defined account splitting and merging table and the account details corresponding to each passive type account, it determines whether each passive type account is a fake account caused by merging or a fake account caused by inconsistent business numbers. This includes: using the pre-built fake account recognition model, based on a pre-defined fake account whitelist, account splitting and merging table, and the account details corresponding to each passive type account, determining whether each passive type account is a fake account caused by merging or a fake account caused by inconsistent business numbers; wherein, the fake account whitelist is used to record normal accounts that are not fake accounts.
[0068] Specifically, a predefined whitelist of false accounts receivable, an account receivable splitting and merging table, and account receivable details corresponding to each passive type account receivable can be input into a pre-built false account receivable identification model for processing to determine whether each passive type account receivable is a false account receivable caused by the merging of transactions or a false account receivable caused by inconsistent business numbers.
[0069] By setting the above, normal accounts that are not false accounts can be avoided from being identified as false accounts, thus improving the efficiency of subsequent account processing.
[0070] S280. Based on the transaction code corresponding to each passive type of posting, determine the posting processing object corresponding to each passive type of posting.
[0071] In this step, specifically, the corresponding posting processing object for each passive posting can be determined based on the transaction code corresponding to each passive posting and the predefined posting processing object table.
[0072] S290. Send the information on whether each passive type of posting is a fake posting, as well as the posting details of each passive type of posting, to the corresponding posting processing object.
[0073] In this step, specifically, false accounts can be removed from each type of passive account receivable, resulting in non-false passive account receivable. Then, a passive account receivable processing solution corresponding to the non-false passive account receivable can be queried from a predefined passive account receivable processing solution library. Finally, the passive account receivable processing solution can be sent to accounting line technical personnel for initial review, and the approved passive account receivable processing solution can be sent to the corresponding account receivable processing object via email or other information transmission methods, while simultaneously tracking the processing progress of the account receivable processing object.
[0074] The advantage of this setup is that using a random forest model for identifying false accounts can improve the accuracy of such identification. Secondly, by identifying false accounts within the passive type of accounts, further processing of false accounts can be avoided, thereby improving the efficiency of processing passive type accounts.
[0075] Optionally, after sending the relevant information of active or passive account accrual to the corresponding account accrual processing object, the processing result can be filled into a preset response template in response to the processing result of the account accrual processing object, and the processing results can be summarized according to the transaction code and business scenario for relevant personnel to review.
[0076] The technical solution in this embodiment determines the bad debt risk of each proactively listed account by associating the listing date and reason with each such account. This improves the accuracy and efficiency of bad debt risk prediction while ensuring its accuracy. Secondly, identifying the account processing object through transaction codes improves the efficiency of task distribution, thereby increasing overall account processing efficiency. Finally, identifying false listings in passively listed accounts improves the efficiency of processing passively listed accounts.
[0077] In a preferred embodiment, RPA technology can be used to encode the following processes into execution logic: the process of technicians identifying and classifying outstanding payment inspection emails; the process of determining and distributing outstanding payment details, bad debt risks, and outstanding payment handling plans corresponding to proactive outstanding payments; the process of identifying false outstanding payments in passive outstanding payments and distributing non-false passive outstanding payments; and the process of tracking the processing progress of outstanding payment objects. This RPA execution logic can then be executed to complete the processing of various types of outstanding payments.
[0078] The requirements state that the user information of users in the outstanding debt scenario collected by this invention is information and data authorized by the users or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for debtor companies to choose to authorize or refuse.
[0079] Example 3
[0080] Figure 3 This is a schematic diagram of the structure of an account receivable processing device according to Embodiment 3 of the present invention. This embodiment is applicable to the processing of account receivables. The account receivable processing device can be implemented in hardware and / or software and can be configured in electronic devices such as computers.
[0081] like Figure 3 As shown, the receivables processing device disclosed in this embodiment includes: an email type determination module 31, a receivables details determination module 32, a receivables analysis module 33, and a receivables processing module 34, wherein:
[0082] The email type determination module 31 is used to obtain each outstanding payment inspection email corresponding to the target object, and determine the email type of each outstanding payment inspection email based on the email subject of each outstanding payment inspection email.
[0083] The receivables details determination module 32 is used to treat receivables inspection emails with the email type of proactive receivables as proactive receivables emails, and based on the proactive receivables emails, determine each proactive type receivable corresponding to the target object, as well as the receivables details information of each proactive type receivable.
[0084] The outstanding accounts analysis module 33 is used to determine the bad debt risk and outstanding accounts processing object corresponding to each active type of outstanding account based on the outstanding account details information corresponding to each active type of outstanding account.
[0085] The post-record processing module 34 is used to send the post-record details and bad debt risk of each proactive post-record to the corresponding post-record processing object.
[0086] The technical solution in this embodiment, through the cooperation of the email type determination module 31, the outstanding account details determination module 32, the outstanding account analysis module 33, and the outstanding account processing module 34, solves the problem that the existing technology requires technical personnel to perform outstanding account analysis, resulting in low efficiency of outstanding account processing, thereby reducing the cost of outstanding account processing and improving the efficiency of outstanding account processing.
[0087] Optionally, the detailed information for proactively listed accounts includes the listing date, reason for listing, and transaction type. Further, the account listing analysis module 33 includes:
[0088] The bad debt risk determination unit is used to determine the bad debt risk of each proactive type of outstanding debt by using a pre-built risk prediction model, based on the outstanding debt date and reason corresponding to each proactive type of outstanding debt.
[0089] The first posting processing unit is used to determine the posting processing object corresponding to each active posting based on the transaction code corresponding to each active posting.
[0090] Optionally, the first posting processing unit is specifically used to: determine the posting processing object corresponding to each active posting based on the transaction code corresponding to each active posting and a predefined posting processing object table; wherein the posting processing object table contains the correspondence between transaction codes and posting processing objects.
[0091] Optionally, the device also includes a fake account recognition module, which includes:
[0092] The passive posting details determination unit is used to treat posting inspection emails of type passive posting as passive posting emails, and based on the passive posting emails, to determine each passive posting corresponding to the target object, as well as the posting details information of each passive posting; wherein, the posting details information of passive posting includes at least the business number and transaction type.
[0093] The fake account recognition unit is used to determine whether each passive account is a fake account caused by the merging of transactions or a fake account caused by inconsistent business numbers, based on a pre-built fake account recognition model, a pre-defined account splitting and merging table, and the account details corresponding to each passive account.
[0094] The processing object determination unit is used to determine the processing object corresponding to each passive type of account based on the transaction code corresponding to each passive type account.
[0095] The second posting processing unit is used to send whether each passive posting is a fake posting and the posting details of each passive posting to the corresponding posting processing object.
[0096] Optionally, the fake account receivable identification unit is specifically used to: determine whether each passive account receivable is a fake account receivable caused by the merging of transactions or a fake account receivable caused by inconsistent business numbers, based on a pre-built fake account receivable identification model, a pre-defined fake account receivable whitelist, an account receivable splitting and merging table, and account receivable details corresponding to each passive account receivable. The fake account receivable whitelist is used to record normal accounts receivable that are not fake accounts.
[0097] Optionally, the fake account receivable identification model is a random forest model.
[0098] The account receivable processing device provided in this embodiment of the invention can execute the account receivable processing method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method execution. Content not described in detail in this embodiment can be referred to the description in any method embodiment of this application.
[0099] Example 4
[0100] Figure 4 A schematic diagram of the structure of an electronic device 10 that can be used to implement embodiments of the present invention is shown. For example... Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.
[0101] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0102] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the accounts receivable processing method.
[0103] In some embodiments, the accounts receivable processing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the accounts receivable processing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the accounts receivable processing method by any other suitable means (e.g., by means of firmware).
[0104] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0105] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0106] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0107] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0108] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.
[0109] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through a communication network. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.
[0110] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.
[0111] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.
Claims
1. A method for handling outstanding accounts, characterized in that, The method includes: Retrieve each outstanding payment check email corresponding to the target object, and determine the email type of each outstanding payment check email based on its subject line. The email type of the deferred payment inspection email is regarded as the deferred payment email, and based on the deferred payment email, each deferred payment corresponding to the target object and the deferred payment details of each deferred payment are determined. Based on the detailed information of each proactive type of receivable, determine the bad debt risk and receivable processing object corresponding to each proactive type of receivable; Send the detailed information of each proactively accrued account and its bad debt risk to the corresponding account processing object.
2. The method according to claim 1, characterized in that, The details of proactively listed accounts include the listing date, reason for listing, and transaction type. Based on the detailed information of each proactively accrued account, determine the bad debt risk and the account handling object corresponding to each proactively accrued account, including: By using a pre-built risk prediction model, the bad debt risk of each proactive type of outstanding account is determined based on the outstanding account date and reason corresponding to each outstanding account. Based on the transaction code corresponding to each active type of posting, determine the posting processing object corresponding to each active type of posting.
3. The method according to claim 2, characterized in that, Based on the transaction code corresponding to each active type of posting, determine the posting processing object corresponding to each active type of posting, including: Based on the transaction code corresponding to each active type of posting and the predefined posting processing object table, determine the posting processing object corresponding to each active type of posting. The pending account processing object table contains the correspondence between transaction codes and pending account processing objects.
4. The method according to claim 1, characterized in that, After determining the email type of each outstanding balance check email based on its subject line, the process also includes: The posting inspection email with the email type of passive posting is regarded as a passive posting email. Based on the passive posting email, each passive posting corresponding to the target object is determined, as well as the posting details of each passive posting. The posting details of the passive posting include at least the business number and transaction type. By using a pre-built fake account identification model, based on a pre-defined account splitting and merging table and the account details corresponding to each passive type account, it is determined whether each passive type account is a fake account caused by the merging of accounts or a fake account caused by inconsistent business numbers. Based on the transaction code corresponding to each passive type of posting, determine the posting processing object corresponding to each passive type of posting; Whether each passive type of posting is a fake posting, and the posting details of each passive type of posting, are sent to the corresponding posting processing object.
5. The method according to claim 1, characterized in that, By using a pre-built fake account recognition model, based on a pre-defined account splitting and merging table and the account details corresponding to each passive type account, it determines whether each passive type account is a fake account caused by merging or by inconsistent business numbers, including: By using a pre-built fake account identification model, based on a pre-defined fake account whitelist, an account splitting and merging table, and account details corresponding to each passive type account, it is determined whether each passive type account is a fake account caused by the merging of accounts or a fake account caused by inconsistent business numbers. The fake account whitelist is used to record normal accounts that are not fake accounts.
6. The method according to claim 4 or 5, characterized in that, The fake account recognition model is a random forest model.
7. An account receivable processing device, characterized in that, The device includes: The email type determination module is used to obtain each outstanding payment inspection email corresponding to the target object, and determine the email type of each outstanding payment inspection email based on the email subject of each outstanding payment inspection email. The receivables details determination module is used to treat receivables inspection emails of the receivables type as receivables emails, and based on the receivables emails, determine each receivable of the receivables type corresponding to the target object, as well as the receivables details information of each receivable of the receivables type. The outstanding accounts analysis module is used to determine the bad debt risk and outstanding accounts processing object corresponding to each active type of outstanding account based on the outstanding account details information. The deferred payment processing module is used to send the deferred payment details and bad debt risk of each actively deferred payment to the corresponding deferred payment processing object.
8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the account receivable processing method according to any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the account receivable processing method according to any one of claims 1-6.
10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the account receivable processing method according to any one of claims 1-6.