Financial management system for business and financial preposed integrated processing and application method

Abstract

The invention provides a financial management system for business and financial preposed integrated processing and an application method, and the system employs a method for automatically driving and activating a settlement module or a delivery module, and recognizes the business attribute of the business data of a current order. And the corresponding settlement module or the delivery module is automatically activated and the order business data is driven and executed, so that the automatic operation level of the system is improved, manual intervention operation is replaced, intelligent land industry finance and taxation integrated management and application are realized, and the operation processing efficiency of industry finance and taxation is greatly improved. A settlement or delivery function can be correspondingly activated according to service attributes, integrated processing and operation of industry finance and taxation are automatically carried out, intelligent management and operation of industry finance and taxation are achieved, efficiency is greatly improved, and cost is greatly reduced.

Description

Technical Field

[0001] This invention relates to the field of business financial management technology, and in particular to a financial management method, a financial management system, an electronic device, and a computer-readable storage medium that integrates business and financial front-end processing. Background Technology

[0002] Currently, the technical principle behind the "business-finance integration" software on the market is generally to configure different accounting vouchers, journal entry templates (and accounting reports) according to different business types. This way, when business personnel enter business data such as "orders" and "payments," the system generates "financial data" based on the templates.

[0003] However, the main drawbacks of the aforementioned technologies are their poor flexibility and accuracy. Because national financial and tax regulations are complex, it's difficult to ensure that the same "business data" generates accurate "financial data" across various business scenarios. Therefore, accounting intervention is often required to modify the automatically generated "financial data" to ensure accuracy, thus hindering true "business-finance integration" and limiting flexibility. Manual intervention, on the other hand, requires not only professional accounting knowledge but also significant time, resulting in a lack of intelligent operation, susceptibility to errors, and insufficient precision. Summary of the Invention

[0004] A financial management method that integrates business and finance processes in advance includes the following steps: A settlement module and a delivery module are pre-built and deployed in a general business operating system. The settlement module is used to confirm the amount receivable / payable and the taxes payable for order business data, and the delivery module is used to confirm the income / expenditure amount for order business data. Retrieve order business data from the order system and send it to the general business operating system; The ordinary business operating system identifies the business attributes of the order business data through a business-driven identification model, generates an activation strategy based on a deep reinforcement learning-based dual-module collaborative decision-making algorithm, and performs settlement processing, delivery processing, or collaborative processing on the order business data, generating and outputting an integrated processing result. The collaborative processing includes automatically determining the execution order or parallel execution based on business attributes, realizing real-time data interaction between modules through a shared data buffer, and ensuring consistency verification between accounts receivable / payable amounts and revenue / expense data. The integrated processing result is then pushed to the payment / goods business system for payment / goods confirmation. The financial system processes accounting vouchers and journal entries based on the integrated processing results after the confirmation of payment / goods, and generates and saves the corresponding financial data.

[0005] Preferably, the business-driven identification model is constructed through the following steps: Based on the LLM large language model and BERT entity recognition technology, order business data from multi-source heterogeneous systems are collected to construct a dynamic dataset M containing industry tags, business model tags and compliance risk levels. Enhanced feature engineering was performed on dataset M to extract basic features, derived features, higher-order features, and deep learning features. The feature set was obtained by a two-stage screening algorithm that combines variance inflation factor (VIF) and improved recursive feature elimination (RFE). The AutoML framework is used to automatically search for the optimal model combination. The base model is an ensemble of LightGBM / XGBoost / Random Forest. Overfitting is suppressed by a three-level regularization strategy, which includes L1 regularization (coefficient = 0.01), random forest sampling (ratio = 0.8), and Dropout layer (ratio = 0.2). The training, validation, and test sets were divided into training, validation, and test sets in a 7:2:1 ratio using stratified sampling. The SMOTE algorithm was used to handle class imbalance. The model was trained using 5-fold cross-validation combined with an early stopping mechanism (patience=5). The model was completed when the validation set F1 score was ≥0.95.

[0006] Preferably, the enhanced feature engineering includes: Basic features: order amount, tax rate, discount rate (numerical); business attribute code, industry tag (categorical); Derivative features: order cycle calculated based on timestamps, customer historical transaction frequency (behavioral); Higher-order features: Business pattern embedding vectors (semantic) obtained by dimensionality reduction through an autoencoder; Deep learning features: Semantic vectors (768-dimensional) of order description text are extracted using a pre-trained BERT model and then reduced to 64-dimensionality using PCA.

[0007] Preferably, the dual-module collaborative decision-making algorithm based on deep reinforcement learning includes: A Markov Decision Process (MDP) model is constructed, using a 128-dimensional feature vector of order business data as the state input. The feature vector includes order amount, business attributes, timestamp, and industry label. The action output is set as the activation of the settlement module, the activation of the delivery module, or the collaboration of both modules. The action space A = {Settlement activation, Delivery activation, Collaboration of both modules}. The policy network is optimized using a composite reward function R(s,a)=0.6×Accuracy+0.4×(1 / TimeCost), where Accuracy is the accuracy of financial data generation and TimeCost is the processing delay. The policy network is updated using the PPO (Proximal Policy Optimization) algorithm, with an experience pool capacity of 100,000 entries. Policy optimization is performed every 1,000 steps, and new business data is incorporated monthly through incremental learning.

[0008] Preferably, the application steps of the model in the integrated settlement and delivery include: (1) Real-time inference: After receiving order data, the business-driven identification model outputs an activation instruction containing the collaborative mode code through the lightweight inference engine (TensorRT). The format is {module identifier + collaborative code + data interlock flag}, and the inference latency is ≤50ms. (2) Collaborative activation: The normal business operating system parses the activation command. If the collaboration code is 0x01, the "settlement → delivery" serial process is executed, and the module data is locked by the status code. If the collaboration code is 0x02, parallel processing is achieved through Redis distributed lock to ensure atomic operation. If the collaboration code is 0x03, the rule engine is triggered to dynamically generate conditional activation strategy. (3) Data consistency verification: The settlement and delivery data fingerprints are compared using the MD5 hash algorithm. The error threshold is ≤0.01%. When an anomaly occurs, the DRL strategy network is dynamically adjusted, and the action value function is updated every 100ms. (4) Feedback Iteration: The daily collection module activation record and financial data generation results are used to calculate the strategy reward value and update the model parameters through the PPO algorithm. When the weekly decay rate of the F1 score is >5%, full retraining is automatically triggered.

[0009] A financial management system that integrates business and finance processes in advance, for implementing the above-described method, comprising: The order system is used to store order business data; A standard business operating system with built-in settlement module, delivery module, business-driven identification model, and dual-module collaborative decision-making unit; The cash / goods business system is used to confirm accounts receivable cash flow or inventory status based on the integrated processing results. A financial system is used to convert confirmed processing results into accounting vouchers and financial data. The model training unit is used for the model building process and includes a dynamic dataset management module, a feature engineering module, and an AutoML training engine.

[0010] Preferably, the general business operating system further includes a data consistency verification module, which performs data verification through the following steps: Monitor key fields in settlement and delivery documents, including amount, tax rate, business attributes, and collaboration mode codes; Data fingerprints are calculated and compared using a consistent hashing algorithm, with an error threshold of ≤0.01%. When an anomaly occurs, an alarm mechanism is triggered, which is simultaneously pushed to the DRL policy network for dynamic adjustment, and the anomaly cases are recorded in the training sample library.

[0011] On the other hand, an electronic device is provided, comprising: a processor; and a memory storing computer-readable instructions, which, when executed by the processor, implement the above-described method.

[0012] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction is stored therein, the at least one instruction being loaded and executed by a processor to implement the above method. The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following: This invention employs a method for automatically activating the settlement module or the delivery module. Simultaneously, the system identifies the business attributes of the current order business data, automatically activates the corresponding settlement module or delivery module, and drives the execution of the order business data. This improves the system's automation level, replaces manual intervention, and realizes intelligent integrated management and application of business, finance, and taxation, greatly improving the efficiency of business, finance, and taxation operations.

[0013] Meanwhile, the settlement and delivery modules are integrated into the standard business operating system, enabling front-end integration of business processing and financial accounting. This avoids information gaps between business and finance in traditional processes and reduces subsequent verification costs. From order data acquisition, business-driven identification, dual-module collaborative processing, payment / goods confirmation to financial voucher generation, the entire process is automated, reducing manual operations and improving processing speed and accuracy. Attached Figure Description

[0014] 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.

[0015] Figure 1 This is a flowchart of a financial management method for integrated business and finance pre-processing provided by an embodiment of the present invention; Figure 2This is a schematic diagram of a dual-module collaborative decision-making process provided by an embodiment of the present invention; Figure 3 This is a block diagram of a financial management system that integrates business and finance processing in advance, as provided in an embodiment of the present invention. Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0016] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0017] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0018] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning.

[0019] In this embodiment of the invention, sometimes a subscript such as W1 may be mistakenly written as a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0020] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0021] like Figure 1 As shown, a financial management method that integrates business and finance processes upfront includes the following steps: A settlement module and a delivery module are pre-built and deployed in a general business operating system. The settlement module is used to confirm the amount receivable / payable and the taxes payable for order business data, and the delivery module is used to confirm the income / expenditure amount for order business data. Retrieve order business data from the order system and send it to the general business operating system; The ordinary business operating system identifies the business attributes of the order business data through a business-driven identification model, generates an activation strategy based on a deep reinforcement learning-based dual-module collaborative decision-making algorithm, and performs settlement processing, delivery processing, or collaborative processing on the order business data, generating and outputting an integrated processing result. The collaborative processing includes automatically determining the execution order or parallel execution based on business attributes, realizing real-time data interaction between modules through a shared data buffer, and ensuring consistency verification between accounts receivable / payable amounts and revenue / expense data. The integrated processing result is then pushed to the payment / goods business system for payment / goods confirmation. The financial system processes accounting vouchers and journal entries based on the integrated processing results after the confirmation of payment / goods, and generates and saves the corresponding financial data.

[0022] Combined with appendix Figure 3 As shown in the system architecture, this invention pre-builds and deploys a settlement module and a delivery module in a general business operating system. The settlement module is used to confirm the amount receivable / payable and the taxes payable in order business data. It automatically calculates taxes through a rule engine (built-in tax rate table and preferential policy matching logic) and supports multi-dimensional allocation rule configuration (proportional / fixed amount / tiered). The delivery module is used to confirm the income / expense amount in order business data. It integrates income recognition criteria judgment logic (such as control transfer condition detection) and supports two modes: partial delivery (split by progress / quantity / amount) and full delivery. The modules achieve data interoperability through standardized API interfaces.

[0023] Order business data is retrieved from the order system and sent to the general business operating system. The general business operating system identifies the business attributes of the order business data through a business-driven identification model, generates an activation strategy based on a deep reinforcement learning-based dual-module collaborative decision-making algorithm, and performs settlement processing, delivery processing, or collaborative processing on the order business data, generating and outputting an integrated processing result. The collaborative processing includes automatically determining the execution order or parallel execution based on business attributes, achieving real-time data interaction between modules through a shared data buffer, and ensuring consistency verification between accounts receivable / payable amounts and revenue / expense data. The integrated processing result is pushed to the payment / goods business system for payment / goods confirmation. The business-driven identification model constructs a 128-dimensional feature vector by integrating LLM and BERT feature extraction techniques. It uses the LightGBM ensemble model optimized by the AutoML framework to achieve business attribute classification (accuracy ≥ 95%). The dual-module collaborative decision-making algorithm is based on the MDP model optimized by PPO. It uses the accuracy of financial data (weight 0.6) and processing timeliness (weight 0.4) as reward functions and dynamically outputs three types of activation strategies: serial collaboration (status code 0x01, settlement → delivery data lock), parallel collaboration (status code 0x02, Redis distributed lock ensures atomicity), and condition-triggered collaboration (status code 0x03, SQL-like rule engine dynamically generates activation conditions).

[0024] Finally, the financial system processes the integrated results of payment / goods confirmation into accounting vouchers and journal entries, generating and saving the corresponding financial data. The accounting voucher generation adopts a dual-engine architecture of template engine + dynamic journal entry rules, with more than 300 industry standard voucher templates preset and supporting user-defined journal entry rules (such as debit: accounts receivable, credit: deferred income + taxes payable). The financial data is standardized and output through XBRL format conversion to meet the requirements of tax declaration and audit traceability. Data storage adopts a distributed database (MySQL cluster) to achieve high availability, and key operation logs are stored on the blockchain to ensure immutability.

[0025] The application principle of the present invention will be further described below.

[0026] Combination Figure 2 As shown, this system mainly consists of an order system, a general business operating system, a payment / goods business system, and a financial system (accounting vouchers and journal entries). The corresponding business, financial, and tax processing flow is as follows: Order system → General business operating system (collaborative decision-making → module processing) → Payment / goods business system (payment / goods confirmation) → Financial system (voucher generation).

[0027] This technical solution mainly involves two functional operations: "settlement" and "delivery." "Settlement" and "delivery" are innovative functional designs of this invention; these two actions do not exist in normal business operations. By establishing these two functional points as a link between "business data" and "financial data," this invention realizes the conversion from "business data" to "financial data," achieving deep collaboration between the "settlement" and "delivery" modules.

[0028] To achieve deep collaboration between the two modules, the system constructs a settlement-delivery status transition matrix and defines three core collaboration modes: (1) Serial collaboration: When an order meets the condition of "confirming revenue after payment" (such as in a retail scenario), the "settlement → delivery" serial process is triggered. The amount of receivable output by the settlement module is automatically used as the revenue confirmation base of the delivery module. Data locking between modules is achieved through status code 0x01. (2) Parallel collaboration: For scenarios such as cross-border trade that require simultaneous processing of taxes and income, the dual-module parallel processing thread is activated, and the atomic operation of tax calculation and income confirmation is ensured through a distributed lock mechanism (implemented by Redis), and the processing latency is controlled within 200ms; (3) Condition-triggered collaboration: Pre-set business rule engine (such as "Automatically trigger partial delivery when project progress ≥ 50%), and dynamically generate activation conditions through the rule engine module, supporting SQL-like rule configuration (example: IF progress>0.5THEN deliver(amount*0.5)).

[0029] To achieve integrated intelligent processing of settlement and delivery, this solution designs a two-module collaborative decision-making algorithm based on deep reinforcement learning (DRL), such as... Figure 2 As shown, the algorithm is defined as follows: By constructing a Markov Decision Process (MDP) model, the order business data features are used as state inputs (including 128-dimensional feature vectors such as order amount, business attributes, and timestamps), and the activation of the settlement / delivery module is used as the action output (action space A={settlement activation, delivery activation, dual-module collaboration}). A composite reward function R(s,a)=0.6×Accuracy+0.4×(1 / TimeCost) is constructed using the accuracy of financial data generation (weight 0.6) and processing timeliness (weight 0.4). The PPO (Proximal Policy Optimization) algorithm is used to optimize the policy network to achieve module collaborative decision-making in a dynamic environment.

[0030] By integrating settlement and delivery modules into the standard business operating system, business processing and financial accounting are pre-processed, avoiding information gaps between business and finance in traditional workflows and reducing subsequent verification costs. From order data acquisition, business-driven identification, dual-module collaborative processing, payment / goods confirmation to financial voucher generation, the entire process is automated, reducing manual operations and improving processing speed and accuracy.

[0031] In this system, two special functions, "Settlement Module" and "Delivery Module," are designed within the ordinary business operating system. In this invention, after a user enters an order, if payment is required, they must first click "Settle" to generate a "Settlement Statement" (this can be done manually, where the user identifies the corresponding business attributes, manually inputs them into the ordinary business operating system, and activates the corresponding module). After the "Settlement Statement" is generated (or approved), the corresponding "Financial Data" is generated: Debit: Accounts Receivable Credit: "Deferred Revenue from Advances from Customers" category Credit: "Taxes Payable" category accounts; If a user has sent or received goods (or provided / received services), they need to click "Deliver" to generate a "Delivery Order." After the delivery order is generated (or approved), the corresponding "Financial Data" will be generated: Debit: "Deferred Revenue from Advances from Customers" account; Credit: "Revenue" category in "Profit and Loss Accounts".

[0032] To generate accurate financial data from "business data," the key points mainly involve confirming three core financial data points (which must comply with relevant national financial and tax regulations): Confirm "Accounts Receivable".

[0033] Confirm "income".

[0034] Confirm "Taxes Payable".

[0035] In this invention, settlement involves confirming "accounts receivable" and "taxes payable"; delivery involves confirming "revenue". The "revenue confirmation" is completed within the "delivery" function. However, some companies' operations only have the "settlement" step, simultaneously confirming "accounts receivable", "revenue", and "taxes payable" within "settlement". The resulting financial data is as follows: Debit: Accounts Receivable Credit: Revenue accounts within the Profit and Loss category. Credit: "Taxes Payable" category.

[0036] Furthermore, when the settlement statement is generated, the "financial data" may not be generated automatically and immediately. Instead, the user may need to perform a related action manually, such as "adding to account" (the name is not fixed), to trigger the generation of the financial data. Whether the "financial data" is generated automatically or manually after a related action is performed, both fall within the scope of protection of the core principles of this invention.

[0037] These two functional modules connect business data and financial data, enabling the conversion of business data into financial data that complies with national tax regulations. This is because the aforementioned three types of data cannot be generated through pre-set templates and traditionally require the involvement of accountants who use their professional knowledge to compile "financial data" based on actual business transactions. With these two functional modules, business personnel simply perform a normal business operation, requiring no specialized accounting knowledge. They only need to trigger these two functions based on the actual situation, and the software will automatically convert the data into "financial data" according to their actions.

[0038] These two functional modules achieve dynamic dependency management through a collaborative decision-making algorithm. The system automatically selects the optimal processing logic based on the order's business attributes: when the business attribute is "one-time delivery of services" (code S01), the "settlement and delivery in parallel" mode is executed; when the attribute is "installment sales of goods" (code G02), the serial mode of "settlement → partial delivery → remaining settlement → full delivery" is executed; when a cross-border transaction identifier (tag T03) is detected, the dual-module data interlocking mechanism is automatically activated to ensure that the customs declaration amount and revenue confirmation data are consistent in real time.

[0039] Therefore, this solution achieves the following functional characteristics: (1) Business-driven identification model: Based on LLM+BERT entity recognition, collect multi-source order data and construct a dynamic dataset containing industry, business model and compliance risk labels; extract multi-dimensional features through enhanced feature engineering (basic / derived / high-order / deep learning features) and adopt VIF+improved RFE two-stage screening; By integrating AutoML with LightGBM / XGBoost / Random Forest and combining three-level regularization (L1, random forest sampling, Dropout) to suppress overfitting, and using SMOTE to handle class imbalance and 5-fold cross-validation + early stopping mechanism for training, we can achieve accurate identification of order business attributes (F1≥0.95).

[0040] The business-driven identification model integrates multi-source features (including textual semantics) and AutoML training, which can accurately identify order business attributes (industry, business model, compliance risks) and provide a reliable basis for collaborative decision-making.

[0041] (2) Dual-module collaborative decision-making algorithm: A Markov decision process (MDP) is constructed, with 128-dimensional features of the order (amount, business attributes, timestamp, industry tag) as the state and settlement / delivery / collaboration as the actions (action space A={settlement activation, delivery activation, dual-module collaboration}); a composite reward function (0.6×accuracy + 0.4×(1 / latency)) is used for optimization, and the policy network is updated through the PPO algorithm, combined with incremental learning to adapt to new business. The dual-module collaborative decision-making algorithm adopts DRL optimization, combined with accuracy and latency optimization strategies, supports serial (status code locking), parallel (Redis distributed lock), and dynamic (rule engine) strategies, with inference latency ≤50ms, improving processing efficiency.

[0042] (3) Data consistency verification: The settlement and delivery data fingerprints are calculated and compared using the MD5 / consistent hash algorithm (error threshold ≤ 0.01%). In case of anomalies, the DRL strategy network is dynamically adjusted, and the action value function is updated every 100ms to ensure data consistency. The settlement and delivery data are verified in real time using the hash algorithm. In case of anomalies, the DRL is dynamically adjusted to ensure that the accounts receivable / payable amount is consistent with the revenue / expenditure data, thereby reducing financial data errors.

[0043] The DRL policy network employs incremental learning (incorporating new data monthly) and daily feedback iteration (PPO parameter updates). It automatically retrains the entire dataset when the F1 weekly decay rate exceeds 5%, adapting to changes in business models and maintaining stable model performance. (4) Business and finance front-end integrated process: Deploy settlement and delivery modules in the front end of the ordinary business operating system, identify order attributes through business-driven identification model, generate activation strategies (serial / parallel / dynamic) using dual-module collaborative decision-making algorithm, push confirmation to the payment / goods system after processing, and then generate accounting vouchers by the financial system to realize business and finance front-end collaboration.

[0044] Taking the engineering industry as an example: Suppose a renovation company receives a 1 million RMB project (with a 9% VAT invoice). They need to enter a "revenue order (or contract)" into the system. The contract stipulates payment in two installments: 30% upon completion of demolition, and the remaining 70% upon full completion.

[0045] Ten days after the project began, the demolition was completed. At this point, the renovation company's project manager needed to click "Settle" in the system, with the settlement amount set at "0.3". This generated the "Financial Data". Debit: Accounts Receivable 300,000 Credit: Deferred revenue from advance receipts 273,000 Credit: Taxes Payable - Value Added Tax 27,000 At this point, an "accounts receivable" of 300,000 is generated in the system. The invoice will then be issued to the customer and payment will be collected at the agreed-upon time.

[0046] Since the project is 30% complete, 30% of the revenue can be recognized financially. Therefore, the project manager only needs to click "Deliver" and enter a delivery order to recognize 30% of the revenue.

[0047] The system automatically identifies this scenario as a "partial settlement + partial delivery" collaborative mode using a dual-module collaborative algorithm. When 30% of the payment is settled, the corresponding percentage of revenue recognition permissions are simultaneously locked. Delivery operations can only be performed on the settled portion, preventing over-recognition of revenue. A collaborative processing log is also generated: [Collaboration ID: 20231027001, Mode: Serial, Settlement Amount: 300,000, Delivery Ratio: 30%, Data Consistency Verification: Passed]: Debit: Deferred revenue from advance receipts 273,000 Credit: Main business revenue 273,000.

[0048] Therefore, this invention achieves the automatic generation of financial data from business data by using "settlement" and "delivery" as a bridge between "business data" and "financial data." Since these two functions do not require accounting knowledge, ordinary business personnel can use them. As long as these functions are used correctly, the generated financial data can be guaranteed to be accurate, eliminating reliance on accounting and truly achieving "business-finance integration."

[0049] This invention solves the problem of the accuracy of "financial data" automatically generated from "business data" in integrated business and finance software without relying on manual accounting intervention, and can ensure that the generated "financial data" in different industries and business scenarios complies with national financial and tax regulations.

[0050] Preferably, if the collaborative processing mode is activated, the settlement and delivery modules achieve real-time data synchronization through a shared memory buffer, specifically including: The accounts receivable amount generated by the settlement module and the revenue amount generated by the delivery module are compared in real time using a consistent hashing algorithm (error threshold ≤ 0.01%). After the comparison is successful, the results are packaged into an integrated processing result and sent to the payment / goods business system. Because the cash / goods business system performs a cash / goods confirmation operation on the integrated processing result, it confirms the cash flow receivable or confirms the inventory; After confirmation, proceed to the next step.

[0051] For payment / goods confirmation procedures, refer to the existing financial procedures for payment / goods confirmation.

[0052] The specific settlement and tax payment rules mentioned above can be found in conjunction with existing national fiscal and tax regulations.

[0053] Furthermore, this invention employs a method for automatically activating the settlement module or the delivery module. Simultaneously, the system identifies the business attributes of the current order business data, automatically activates the corresponding settlement module or delivery module, and drives the execution of the order business data. This improves the system's automation level, replaces manual intervention, and realizes intelligent integrated management and application of business, finance, and taxation, greatly improving the efficiency of business, finance, and taxation operations.

[0054] Preferably, the business attribute identification and module activation process is optimized as follows: Receive the order business data and import it into the business-driven identification model pre-deployed in the ordinary business operating system; The business-driven identification model identifies the business attributes of the order business data and outputs a system activation instruction containing the collaboration mode code (format: module identifier + collaboration code + data interlock flag, example: S01|0x02|1). The ordinary business operating system responds to the system activation command to activate the corresponding settlement module or delivery module.

[0055] This solution deploys a business-driven identification model in a regular business operating system. This model can identify the business attributes of order business data entering the model and automatically match and output corresponding business-driven strategies based on the business attributes of the order business data. The strategies include system activation instructions (or control parameters) to activate the corresponding settlement module or delivery module, thereby automating the business-driven execution of order business data and avoiding manual intervention.

[0056] In the aforementioned application process, a typical business operating system generates a large amount of settlement / delivery activation execution logs (activation operation records) of order business data. Therefore, it can batch-save the corresponding order business-driven big data, which includes data on the driving execution behavior of order business data with different attributes. This data can then be used to construct a training dataset for training a business-driven recognition model. The construction method of the business-driven recognition model will be described below.

[0057] The dataset construction adds new collaborative mode feature dimensions, specifically including: (1) collaborative mode label (serial=0, parallel=1, conditional trigger=2); (2) module interaction frequency (unit: times / order); (3) data consistency verification result (pass=1, fail=0). The model trained with the new features can automatically identify the optimal collaborative strategy, and the collaborative decision accuracy in the manufacturing scenario is improved to 97.3%.

[0058] Preferably, the method for constructing the business-driven identification model includes: Based on the LLM large language model and BERT entity recognition technology, combined with the federated learning framework, order business data from multiple heterogeneous systems (order system / CRM / ERP) are collected in batches to construct a dynamic federated order business-driven dataset M. M = {m1, m2, ..., mn}, where m1, m2, ..., mn represent each group of orders. A scenario-based tagging system is introduced, m = {order business data, business attributes, settlement / delivery activation records, industry tags (such as retail / engineering / service), business model tags (such as one-time delivery / installment settlement), compliance risk level (high / medium / low)}. The dataset is automatically updated monthly, and new business types (such as cross-border e-commerce orders and subscription services) are incorporated through an incremental learning mechanism to ensure data timeliness.

[0059] m = {order business data, business attributes, settlement / delivery activation records}; Enhanced feature engineering is performed on the order business-driven dataset M, employing a dual-track extraction approach of "traditional features + deep learning features": (1) Basic characteristics: order amount, tax rate, discount rate (numerical); business attribute code, industry label (category); (2) Derivative features: order cycle and customer historical transaction frequency (behavioral type) calculated based on timestamps; (3) Higher-order features: Business pattern embedding vectors (semantic) obtained by dimensionality reduction through an autoencoder; (4) Deep learning features: The semantic vector (768-dimensional) of the order description text is extracted by the pre-trained BERT model, and the business pattern embedding vector (semantic) is obtained by dimensionality reduction by autoencoder, and then reduced to 64-dimensional by PCA; Features were screened using the variance inflation factor (VIF) (VIF<10) to remove the effects of multicollinearity.

[0060] The feature set is divided into training, validation and test sets in a 7:2:1 ratio using stratified sampling to ensure that the proportion of labels in each industry is consistent. The SMOTE algorithm is used to deal with the class imbalance problem in the training set (when the proportion of a certain class of samples is <10%).

[0061] To collect the training dataset, this section uses the LLM large language model to batch collect the business attribute identification results of the order business data by the ordinary business operating system and the settlement / delivery activation records generated based on the business attributes, including the following descriptions (I) to (IV): (I) Specific Implementation Process 1. LLM API Port Deployment A lightweight API service is built using the FastAPI framework, exposing a POST interface ` / llm / extract` to receive extraction requests from business systems. The interface parameters are designed as follows: Request parameters: prompt (LLM prompt word, string), input_data (order business data to be extracted, JSON format, including fields such as order status, settlement amount, delivery address, etc.); Response parameters: extracted_data (structured extraction results, JSON array, containing order business attributes and activation records that meet the criteria).

[0062] The API service is deployed on the intranet server of the business system and uses OAuth2.0 for authentication to ensure secure data transmission.

[0063] 2. Keyword Extraction and Logical Construction Settlement orders: Extract the keyword set: K_settlement = {"settlement amount", "settlement status", "settlement time"}; Corresponding business system field: F_settlement = {"settlement_amount", "settlement_status", "settlement_time"}; Batch extraction logic: L_settlement = "Order status (order_status) == 'Completed' and settlement_amount > 0".

[0064] Delivery orders: Extract the keyword set: K_delivery = {"delivery address", "delivery time", "activation status"}; Corresponding business system field: F_delivery = {"delivery_address", "delivery_time", "activation_status"}; Batch extraction logic: L_delivery = "Order status (order_status) == 'delivered' and activation_status != 'not activated'".

[0065] 3. LLM prompt construction A template-based generation method is adopted to unify the cue word structure and ensure consistent understanding within the LLM framework. The cue word template is defined as follows: Please extract the {Extraction Type} information from the following order business data, which must include the field {Field List} (corresponding to the business system field names: {Field Name List}). The extraction condition is: {Logical Condition}. The returned result must be in structured JSON format, with the key being the business system field name.

[0066] in: Extraction type: Values ​​can be "Settlement" or "Delivery"; Field list: Values ​​can be K_settlement or K_delivery (e.g., "settlement amount, settlement status, settlement time"); List of field names: Values ​​can be F_settlement or F_delivery (e.g., "settlement_amount", "settlement_status", "settlement_time"); Logical condition: The value is either L_settlement or L_delivery (e.g., "order status (order_status) == 'complete' and settlement_amount > 0").

[0067] Example (checkout prompt): Please extract settlement information from the following order data, including the fields: settlement amount, settlement status, and settlement time (corresponding to the business system field names: settlement_amount, settlement_status, and settlement_time). The extraction criteria are: order status (order_status) == 'Completed' and settlement_amount > 0. The returned result must be in structured JSON format, with the key being the business system field name.

[0068] 4. LLM monitoring and batch data acquisition Use a cron job (triggered every 30 minutes) to execute the following process: Data Acquisition: Query the business conversion processing logs (including fields such as order status, settlement amount, and delivery address) from the business system database for the most recent 30 minutes, and convert them into JSON format input_data; Prompt generation: Fill the above prompt template into input_data to generate a prompt for the current batch of data; LLM call: Send a POST request to the / llm / extract interface, passing prompt and input_data; Output: LLM interprets the extraction requirements based on the prompt, identifies orders that meet the conditions from input_data, and outputs extracted_data (a structured JSON array), which contains: Business attribute identification results (such as settlement_status, activation_status)); Settlement / delivery activation records (such as settlement_amount (settlement amount)) (Settlement time), delivery_address, delivery_time).

[0069] (II) Algorithm Formula Design and Operation Mechanism 1. Business Attribute Recognition Probabilistic Model Formula definition: For order data d, the target field set F = F_settlement ∪ F_delivery (F contains all fields to be extracted), and LLM outputs the extraction probability P(f|d) for each field f∈F (representing the confidence that d contains f). The extraction rule is:

[0070] in: r_f(d): Extraction flag for field f (1 indicates successful recognition, 0 indicates unrecognized); θ: Confidence threshold (set to 0.9, adjusted according to business needs to balance precision and recall).

[0071] Operating mechanism: LLM uses the Transformer's self-attention mechanism to encode the contextual information of the prompt (extraction requirement) and input_data (order data), learning the association pattern between field f and order features (such as order status and amount), and outputting P(f|d). For example, when the order status is "completed" and the settlement amount is greater than 0, The probability of extraction in the settlement state will be significantly higher than θ, triggering... =1.

[0072] 2. Settlement / Delivery Activation Record Settlement activation record: A settlement activation record S(d) is generated when order d meets the following conditions:

[0073]

[0074]

[0075]

[0076]

[0077] .

[0078] Delivery activation record: A delivery activation record D(d) is generated when order d meets the following conditions:

[0079]

[0080]

[0081]

[0082]

[0083] .

[0084] The mechanism is as follows: After LLM outputs extracted_data, valid orders are filtered according to the above rules: The settlement activation record must meet both conditions simultaneously: "settlement status successfully identified and marked 'successful'" and "settlement amount successfully identified". Delivery activation records must simultaneously meet two conditions: "Activation status successfully identified and marked as 'activated'" and "Delivery address successfully identified." Filtered records are stored in a data warehouse for subsequent financial settlement or logistics tracking.

[0085] (III) Working Principle The core logic of the LLM-based batch data acquisition process is as follows: Instruction comprehension: Transform business requirements (such as "retrieve settlement orders") into natural language instructions that LLM can understand through prompt words; Pattern recognition: LLM uses pre-trained contextual understanding capabilities to identify order data that meets extraction criteria (such as "order status is completed") from business logs. Structured output: Converts unstructured / semi-structured log data into structured activation records, facilitating subsequent system integration; Automated loop: A closed loop of "data acquisition - LLM extraction - result storage" is achieved through scheduled tasks, without the need for manual intervention.

[0086] Therefore, it supports processing more than 1,000 order data entries every 30 minutes with a processing time of less than 5 minutes, significantly improving efficiency compared to manual extraction. The LLM achieves a 96% accuracy rate in identifying business attributes (based on 1,000 test data entries, compared to manual annotation), which is higher than traditional rule engines, reducing false and missed extractions. When business requirements change (such as adding extraction fields or adjusting conditions), only the prompt word template needs to be modified, without modifying the API code, reducing the response time from 2 days to 1 hour. Semi-structured logs are converted into structured active records, facilitating import into financial systems (settlement statistics) and logistics systems (delivery tracking), thus improving data utilization.

[0087] The training set is input into the improved AutoML framework (TPOT), which automatically searches for the optimal combination of models through the following four-stage process: (1) Model configuration: The basic model selected is LightGBM / XGBoost / Random Forest ensemble. The hyperparameter search space is set as follows: learning rate ∈ [0.01, 0.1] (step size 0.01), tree depth ∈ [3, 10] (step size 1), number of leaf nodes ∈ [15, 63] (step size 2). The F1 score is used as the optimization objective, and the parameters are optimized by Bayesian optimization algorithm (TPE). (2) Training strategy: Implement stratified 5-fold cross-validation (stratified by industry label), and perform the following for each fold of data: ① Feature standardization → ② Model training → ③ Validation set evaluation; Combine with early stopping mechanism (patience=5, that is, if the F1 score on the validation set does not improve for 5 consecutive rounds, stop training the current model) to save the model parameters of the optimal iteration round; (3) Regularization scheme: A three-level regularization strategy is adopted to suppress overfitting: ① L1 regularization (coefficient = 0.01) controls the sparsity of feature weights; ② Random forest sampling (sample ratio = 0.8, feature ratio = 0.9) enhances model diversity; ③ Dropout layer (ratio = 0.2) prevents deep learning feature overfitting. (4) Model integration: The top 5 models obtained by the search (ranked by F1 score) are integrated by weighted voting (weights are allocated according to cross-validation scores) to construct the business-driven identification model; the integrated model can only be deployed after being validated by the test set (F1 score ≥ 0.95).

[0088] The advantages of implementing this technical solution include: ① Automated model optimization: The TPOT framework automatically completes feature selection, model selection, and hyperparameter tuning, reducing the traditional manual trial-and-error cycle from 2 weeks to 8 hours, improving efficiency by 90%; ② High-precision prediction capability: By integrating the advantages of multiple models through ensemble learning, the accuracy of business attribute recognition reaches 97.3%, which is 4.2% higher than the single LightGBM model; ③ Strong generalization guarantee: The combination of hierarchical cross-validation and dynamic regularization ensures that the average F1 score standard deviation of the model is ≤0.03 in 12 industry scenarios, solving the industry adaptation problem; ④ Enhanced interpretability: Visualize feature importance through SHAP values ​​(core feature weight ratio ≥ 65%) to meet regulatory compliance requirements in financial scenarios.

[0089] Three-level validation is performed using validation and test sets, and a dynamic precision correction function is embedded: (1) Validation set evaluation: accuracy, precision, recall, F1 score (target value ≥ 0.95); (2) Test set evaluation: confusion matrix analysis, Top-K error case tracing (K=20); (3) Model interpretability: The importance of features is calculated by SHAP value to ensure that the weight of core features (such as order amount and business attributes) is ≥60%.

[0090] (4) Accuracy correction function: Based on Bayesian optimization, the classification threshold is dynamically adjusted. When the F1 score on the test set is <0.95, the threshold optimization is automatically triggered: threshold=argmax(F1_score(y_true, y_pred_proba>threshold)), to ensure the robustness of the model in different business scenarios.

[0091] If the verification is successful, the business-driven identification model is deployed and applied in the ordinary business operating system; If the verification fails, repeat the above steps to rebuild the business-driven identification model.

[0092] The training and deployment steps for the business-driven recognition model are as follows: (I) Definition of Target and Input / Output Objective: Based on the order business-driven dataset M, train a business-driven identification model to identify business attributes and predict settlement / delivery activation instructions (including collaborative pattern encoding).

[0093] enter: Order Business-Driven Dataset Each set of data Include: Order business data (such as amount, cost, tax rate, etc.); Business attributes (such as sales, procurement, logistics, and service); Settlement / delivery activation records (such as settlement module, delivery module).

[0094] Output: Output: The trained business-driven recognition model supports outputting business attributes and activation instructions after inputting order data.

[0095] (II) Implementation Steps 1. Dynamic Dataset Construction and Augmentation (Integrating Multi-Source Heterogeneous Data Based on a Federated Learning Framework) Data format: (1) Multi-source data fusion: Integrate data from the order system, CRM system and financial system, and supplement features such as customer credit rating and historical transaction frequency; (2) Contextualized labeling: The labeling system is defined by business experts, such as industry labels (retail=1, engineering=2) and business model labels (one-time=0, installment=1). (3) Incremental update mechanism: new order data (accounting for ≥10%) is automatically included every month, and the sliding window strategy is used to retain the data of the most recent 12 months.

[0096] Each set of data The structure is as follows (taking the settlement module as an example): { "Order Business Data":{ "Order ID":"1001", Amount: 2000 Cost: 1500 Tax rate: 0.13 Discount: 100 "Logistics cost": 0, Service fee: 0 }, Business Attribute: "Sales" "Activation Record": "Settlement Module" }

[0097] 2. Enhanced Feature Engineering (1) Feature extraction: Basic features: Amount, cost, tax rate, discount (numerical); business attributes, industry tags (categorical); Derivative features: Order amount / customer's historical average order amount (percentage feature), logistics cost / total amount (cost percentage feature); High-order features: Use an autoencoder to convert the business description text into a 128-dimensional embedding vector; (2) Feature selection: A two-stage screening algorithm integrating variance inflation factor (VIF) and improved recursive feature elimination (RFE) is designed, as follows: Phase 1: Collinearity Filtering (VIF Test) Algorithm definition: Multicollinearity is detected by calculating the variance inflation factor between features, with the formula VIF_i = 1 / (1-R_i²), where R_i² represents the goodness of fit of the i-th feature to the linear regression of all other features; Operating mechanism: 1. Construct a correlation coefficient matrix for all numerical features and identify highly correlated feature groups with |r|≥0.8. 2. Sort features in descending order of VIF value and iteratively remove features with VIF>10 until all features have VIF≤10. Phase Two: Importance Ranking (Improved RFE) Algorithm definition: Feature importance elimination based on the LightGBM model, the formula is Importance_j = Σ(split_gain_j / total_gain), where split_gain_j represents the total information gain of feature j in tree splitting, and Importance_j represents the feature importance of feature j; Operating mechanism: 1. Initialize feature set F, train the LightGBM model and calculate feature importance scores; 2. Remove the lowest 5% of features and update feature set F'; 3. Repeat steps 1-2 until 20 features remain, retaining the feature subset from the last round; For example, the process of filtering orders based on characteristics for a retail company: The initial feature set contained 35 features. VIF testing revealed the following: - Relevant feature groups: {Order Amount, Tax Amount, Total Price Including Tax} (VIF values ​​were 28.6 / 25.3 / 31.2 respectively). - After removing "Total Price Including Tax," the VIF values ​​of the remaining features were all <10, so 32 features were retained. RFE Iterative Screening: - Round 1 Removal: Customer address code, postal code (importance ranking 31-32) - Round 5 Removal: Logistics method code, payment channel (importance ranking 21-22) - Final retention of Top 20 features, including: order amount (0.12), business attributes (0.09), customer historical transaction frequency (0.08), etc. (the numbers in parentheses are normalized importance scores); (3) Feature transformation: numerical features are standardized (Z-Score), and categorical features are targeted encoding (for high cardinality features such as customer ID).

[0098] 3. Scientific partitioning of the dataset Partitioning strategy: Based on the order business-driven dataset M, stratified sampling is used to divide the dataset into training set, validation set and test set in a ratio of 7:2:1 to ensure consistent label distribution across industries; the SMOTE-NC algorithm is used to handle class imbalance (minority class ratio < 1:5) in the training set.

[0099] 4. AutoML Model Training Functions and Dynamic Optimization Model parameters: (1) Training function definition: train_model(X_train, y_train, X_val, y_val) → Business-driven recognition model Core logic: Integrates the TPOTAutoML framework to automatically search for the optimal model combination (LightGBM / XGBoost / Random Forest), with a built-in learning rate scheduler (cosine annealing strategy: learning_rate=0.05→0.001), and dynamically adjusts the tree depth (3-10 layers adaptively). Regularization enhancement: Combining a three-level regularization strategy (L1 regularization coefficient = 0.01, random forest sampling ratio = 0.8, Dropout layer ratio = 0.2) with an early stopping mechanism (patience = 5), overfitting is suppressed through 5-fold cross-validation, and the objective function is to maximize the F1 score on the validation set; (2) Training strategy: 5-fold cross-validation, early stopping mechanism (patience=5, monitor='f1_macro'); (3) Hyperparameter optimization: Bayesian optimization is used to search for the optimal parameter combination, with the objective function being the F1 score on the validation set.

[0100] Number of trees (`n_estimators`): 100 Maximum depth (`max_depth`): 10, Random seed (`random_state`): 42.

[0101] After multiple iterations of training, a business-driven recognition model was obtained. The next step is validation.

[0102] 5. Accuracy correction function and multi-dimensional verification Verification metrics: (1) Performance indicators: Main metrics: Test set F1 score ≥ 0.95, precision ≥ 0.94, recall ≥ 0.96; Secondary metrics: Diagonal elements in the confusion matrix account for ≥95% of the total; Manual review pass rate for Top-K error cases (K=20) is ≥90%. (2) Model interpretability: Feature importance is calculated using SHAP values, with core features (such as order amount and business attributes) accounting for ≥60% of the weight; (3) Robustness test: Add 10% noise data (such as random disturbance amount ±5%) to the test set, and the model performance decay ≤3%.

[0103] (4) Precision correction function: calibrate_threshold(y_true, y_pred_proba) → optimal_threshold This process involves the user using a validation set to input a business-driven identification model and validating it based on multiple metrics. If the performance verification is successful, the model is deployed.

[0104] Deployment requirements: The test set F1 score is ≥0.95, precision is ≥0.94, recall is ≥0.96, and F1 score is ≥0.95.

[0105] Deployment method: Save the trained business-driven recognition model as a file (e.g., `lgbm_model.pkl`), integrate the model monitoring module (real-time tracking of F1 score decay rate and settlement / delivery collaborative decision accuracy), and automatically trigger incremental training when the decay rate > 5%.

[0106] 6. Model Monitoring and Iteration (1) Real-time monitoring: Deploy Prometheus to monitor model inference latency (≤100ms) and accuracy drift (weekly decay rate ≤1%). (2) Automatic iteration: monthly incremental training, new data is incorporated and parameters are re-optimized, and model version management is implemented (e.g., `lgb_model_v2.1.pkl`). (3) Anomaly handling: When the F1 score is <0.92, the system will automatically roll back to the historical best model and trigger manual intervention.

[0107] 7. Steps for applying the model in integrated settlement and delivery: (1) Real-time inference: The business-driven identification model receives order business data pushed by the order system, performs 128-dimensional feature vectorization based on the feature distribution of dataset M, and outputs activation instructions containing cooperative mode encoding (format: module identifier + cooperative code + data interlock flag) through the lightweight inference engine (TensorRT). The inference latency is ≤50ms. (2) Dual-module collaborative activation: The ordinary business operating system parses the activation command. If the collaboration code is 0x01 (serial), the "settlement → delivery" process is executed. The amount of receivable generated by the settlement module is automatically written to the shared memory buffer. If the collaboration code is 0x02 (parallel), the dual modules are activated synchronously through the Redis distributed lock to ensure that the tax payable and revenue confirmation data are updated atomically. (3) Data consistency verification: The model monitors the key fields (amount, tax rate, business attributes) of the settlement order and delivery order in real time, and compares the data fingerprints through the consistent hashing algorithm (MD5). The error threshold is ≤0.01%. When there is an anomaly, the DRL strategy network is dynamically adjusted (the action value function is updated every 100ms). (4) Feedback Iteration: Collect the actual activation records and financial data generation results of the settlement / delivery module daily, calculate the strategy reward value R(s,a)=0.6×accuracy+0.4×(1 / processing latency), update the DRL policy network through the PPO algorithm, set the experience pool capacity to 100,000, and perform policy optimization once every 1,000 steps. (4) Feedback Iteration: Collect the actual activation records and financial data generation results of the settlement / delivery module daily, calculate the strategy reward value R(s,a)=0.6×accuracy+0.4×(1 / processing delay), update the DRL strategy network through the PPO algorithm, set the experience pool capacity to 100,000, and perform strategy optimization once every 1,000 steps.

[0108] Optimization strategy: (1) LightGBM parameter tuning: Search for the best parameter combination through Bayesian optimization, focusing on optimizing num_leaves (31-127), min_child_samples (5-20), and subsample_ratio (0.7-0.9); (2) Enhanced DRL algorithm: The PPO (Proximal Policy Optimization) algorithm is introduced to optimize the collaborative strategy. The experience pool capacity is set to 100,000 entries, and the policy network is updated every 1,000 steps. (3) Dynamic feature updates: Monthly feature importance reassessment is performed, redundant features with a weight of <0.01 are eliminated, and industry-specific features are added (such as "repurchase rate" for e-commerce and "project progress" for engineering).

[0109] Iteration process: (1) Daily incremental training: Use the newly added order data of the day (≥500) to fine-tune the model and retain the historical best model weights; (2) Dual model verification: When the deviation rate between the collaborative pattern code output by the business-driven recognition model and the actual business scenario is >3%, the manual review process is triggered, and the result is included in the training sample library; (3) Performance warning mechanism: If the F1 score is <0.95 for 3 consecutive days, full retraining will be started automatically and an alarm notification will be sent.

[0110] This solution enables the construction of an efficient and accurate business-driven identification model, which can be successfully deployed into the business operating system to achieve automated processing of order data and integrated decision-making for settlement and delivery.

[0111] Therefore, this invention adopts a DQN (Deep Q-Network) network architecture, learning the module activation sequences of historical orders through an experience replay mechanism. This allows for the automatic identification of business scenarios such as "settlement before delivery" and "parallel settlement and delivery," improving decision accuracy compared to traditional RF models. An attention mechanism is introduced to assign high weights to key business features (such as contract amounts > 5 million and cross-border transaction identifiers), improving feature processing speed and ensuring millisecond-level response in high-concurrency scenarios. An ε-greedy strategy balances exploration and utilization, automatically updating the training sample library monthly (incorporating new business types such as subscription services), enhancing model generalization ability compared to static training. A transfer learning framework is introduced, pre-training a basic model based on 100,000+ general order data. For vertical industries (such as manufacturing / service industries), only 500+ samples are needed for fine-tuning to achieve the target performance, shortening the scenario adaptation cycle and solving the model convergence problem in industries with small sample sizes.

[0112] Figure 3 This is a block diagram of a financial management system for integrated business and finance pre-processing, according to an exemplary embodiment. This system is used to implement the aforementioned integrated business and finance pre-processing financial management method. (Refer to...) Figure 3 ,include: The order system is used to store order business data; A standard business operating system with built-in settlement module, delivery module, business-driven identification model, and dual-module collaborative decision-making unit; The cash / goods business system is used to confirm accounts receivable cash flow or inventory status based on the integrated processing results. A financial system is used to convert confirmed processing results into accounting vouchers and financial data. The model training unit is used for the model building process and includes a dynamic dataset management module, a feature engineering module, and an AutoML training engine.

[0113] Preferably, the general business operating system further includes a data consistency verification module, which performs data verification through the following steps: Monitor key fields in settlement and delivery documents, including amount, tax rate, business attributes, and collaboration mode codes; Data fingerprints are calculated and compared using a consistent hashing algorithm, with an error threshold of ≤0.01%. When an anomaly occurs, an alarm mechanism is triggered, which is simultaneously pushed to the DRL policy network for dynamic adjustment, and the anomaly cases are recorded in the training sample library.

[0114] Please refer to the corresponding methods and steps above to understand the functions and interactions of each system; they will not be elaborated upon here.

[0115] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention, such as... Figure 4 As shown, electronic device 410 may include a first processor 2001.

[0116] Optionally, the electronic device 410 may also include a memory 2002 and a transceiver 2003.

[0117] The first processor 2001, memory 2002, and transceiver 2003 can be connected via a communication bus.

[0118] The following is combined with Figure 4 A detailed description of each component of electronic device 410 is provided below: The first processor 2001 is the control center of the electronic device 410. It can be a single processor or a collective term for multiple processing elements. For example, the first processor 2001 can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of the present invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0119] Optionally, the first processor 2001 can perform various functions of the electronic device 410 by running or executing software programs stored in the memory 2002 and calling data stored in the memory 2002.

[0120] In a specific implementation, as one example, the first processor 2001 may include one or more CPUs, for example... Figure 4 CPU0 and CPU1 are shown in the diagram.

[0121] In a specific implementation, as one example, the electronic device 410 may also include multiple processors, for example... Figure 4The first processor 2001 and the second processor 2004 are shown in the diagram. Each of these processors can be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). Here, a processor can refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0122] The memory 2002 is used to store the software program that executes the present invention, and is controlled by the first processor 2001 to execute it. The specific implementation method can be referred to the above method embodiment, and will not be repeated here.

[0123] Optionally, the memory 2002 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 2002 may be integrated with the first processor 2001 or may exist independently and be connected via the interface circuit of the electronic device 410. Figure 4 (Not shown in the image) is coupled to the first processor 2001, and this embodiment of the invention does not specifically limit this.

[0124] The transceiver 2003 is used to communicate with network devices or with terminal devices.

[0125] Alternatively, transceiver 2003 may include a receiver and a transmitter. Figure 4 (Not shown separately). The receiver is used to implement the receiving function, and the transmitter is used to implement the transmitting function.

[0126] Optionally, the transceiver 2003 can be integrated with the first processor 2001, or it can exist independently and be connected via the interface circuit of the electronic device 410. Figure 4 (Not shown in the image) is coupled to the first processor 2001, and this embodiment of the invention does not specifically limit this.

[0127] It should be noted that, Figure 4 The structure of the electronic device 410 shown does not constitute a limitation on the router. Actual knowledge structure identification devices may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0128] Furthermore, the technical effects of the electronic device 410 can be referred to the technical effects of the method described in the above method embodiments, and will not be repeated here.

[0129] It should be understood that the first processor 2001 in the embodiments of the present invention may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

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

Claims

1. A financial management method that integrates business and finance processes in advance, characterized in that, include: A settlement module and a delivery module are pre-built and deployed in a general business operating system. The settlement module is used to confirm the amount receivable / payable and the taxes payable for order business data, and the delivery module is used to confirm the income / expenditure amount for order business data. Retrieve order business data from the order system and send it to the general business operating system; The ordinary business operating system identifies the business attributes of the order business data through a business-driven identification model, generates an activation strategy based on a deep reinforcement learning-based dual-module collaborative decision-making algorithm, and performs settlement processing, delivery processing, or collaborative processing on the order business data, generating and outputting an integrated processing result. The collaborative processing includes automatically determining the execution order or parallel execution based on business attributes, realizing real-time data interaction between modules through a shared data buffer, and ensuring consistency verification between accounts receivable / payable amounts and revenue / expense data. The integrated processing result is then pushed to the payment / goods business system for payment / goods confirmation. The financial system processes accounting vouchers and journal entries based on the integrated processing results after the confirmation of payment / goods, and generates and saves the corresponding financial data.

2. The method according to claim 1, characterized in that, The business-driven identification model is constructed through the following steps: Based on the LLM large language model and BERT entity recognition technology, order business data from multi-source heterogeneous systems are collected to construct a dynamic dataset M containing industry tags, business model tags and compliance risk levels. Enhanced feature engineering was performed on dataset M to extract basic features, derived features, higher-order features, and deep learning features. The feature set was obtained by a two-stage screening algorithm that combines variance inflation factor (VIF) and improved recursive feature elimination (RFE). The AutoML framework is used to automatically search for the optimal model combination. The base model is an ensemble of LightGBM / XGBoost / Random Forest. Overfitting is suppressed by a three-level regularization strategy, which includes L1 regularization (coefficient = 0.01), random forest sampling (ratio = 0.8), and Dropout layer (ratio = 0.2). The training, validation, and test sets were divided into training, validation, and test sets in a 7:2:1 ratio using stratified sampling. The SMOTE algorithm was used to handle class imbalance. The model was trained using 5-fold cross-validation combined with an early stopping mechanism (patience=5). The model was completed when the validation set F1 score was ≥0.

95.

3. The method according to claim 2, characterized in that, The enhanced feature engineering includes: Basic features: order amount, tax rate, discount rate (numerical); business attribute code, industry tag (categorical); Derivative features: order cycle calculated based on timestamps, customer historical transaction frequency (behavioral); Higher-order features: Business pattern embedding vectors (semantic) obtained by dimensionality reduction through an autoencoder; Deep learning features: Semantic vectors (768-dimensional) of order description text are extracted using a pre-trained BERT model and then reduced to 64-dimensionality using PCA.

4. The method according to claim 1, characterized in that, The dual-module collaborative decision-making algorithm based on deep reinforcement learning includes: A Markov Decision Process (MDP) model is constructed, using a 128-dimensional feature vector of order business data as the state input. The feature vector includes order amount, business attributes, timestamp, and industry label. The action output is set as the activation of the settlement module, the activation of the delivery module, or the collaboration of both modules. The action space A = {Settlement activation, Delivery activation, Collaboration of both modules}. The policy network is optimized using a composite reward function R(s,a)=0.6×Accuracy+0.4×(1 / TimeCost), where Accuracy is the accuracy of financial data generation and TimeCost is the processing delay. The policy network is updated using the PPO (Proximal Policy Optimization) algorithm, with an experience pool capacity of 100,000 entries. Policy optimization is performed every 1,000 steps, and new business data is incorporated monthly through incremental learning.

5. The method according to claim 1, characterized in that, The application steps of the model in integrated settlement and delivery include: (1) Real-time inference: After receiving order data, the business-driven identification model outputs an activation instruction containing the collaborative mode code through the lightweight inference engine (TensorRT). The format is {module identifier + collaborative code + data interlock flag}, and the inference latency is ≤50ms. (2) Collaborative activation: The normal business operating system parses the activation command. If the collaboration code is 0x01, the "settlement → delivery" serial process is executed, and the module data is locked by the status code. If the collaboration code is 0x02, parallel processing is achieved through Redis distributed lock to ensure atomic operation. If the collaboration code is 0x03, the rule engine is triggered to dynamically generate conditional activation strategy. (3) Data consistency verification: The settlement and delivery data fingerprints are compared using the MD5 hash algorithm. The error threshold is ≤0.01%. When an anomaly occurs, the DRL strategy network is dynamically adjusted, and the action value function is updated every 100ms. (4) Feedback Iteration: The daily collection module activation record and financial data generation results are used to calculate the strategy reward value and update the model parameters through the PPO algorithm. When the weekly decay rate of the F1 score is >5%, full retraining is automatically triggered.

6. A financial management system that integrates business and finance processes, used to implement the method described in any one of claims 1-5, characterized in that, include: The order system is used to store order business data; A standard business operating system with built-in settlement module, delivery module, business-driven identification model, and dual-module collaborative decision-making unit; The cash / goods business system is used to confirm accounts receivable cash flow or inventory status based on the integrated processing results. A financial system is used to convert confirmed processing results into accounting vouchers and financial data. The model training unit is used for the model building process and includes a dynamic dataset management module, a feature engineering module, and an AutoML training engine.

7. The system according to claim 6, characterized in that, The general business operating system also includes a data consistency verification module, which performs data verification through the following steps: Monitor key fields in settlement and delivery documents, including amount, tax rate, business attributes, and collaboration mode codes; Data fingerprints are calculated and compared using a consistent hashing algorithm, with an error threshold of ≤0.01%. When an anomaly occurs, an alarm mechanism is triggered, which is simultaneously pushed to the DRL policy network for dynamic adjustment, and the anomaly cases are recorded in the training sample library.

8. An electronic device, characterized in that, The electronic device includes: processor; A memory storing computer-readable instructions that, when executed by the processor, 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 contains program code that can be invoked by a processor to execute the method as described in any one of claims 1 to 6.

Images