Settlement fee automatic accounting method and system based on fund model definition

Abstract

The application provides a settlement cost automatic accounting method and system based on a fund model definition. The method comprises the following steps: obtaining audited and confirmed settlement basic data under a target project, and establishing a data collection unit; obtaining a fund model definition corresponding to the target project; parsing each settlement cost into a fund accounting unit containing a payment side, a collection side, a data reference side and a rule calculation side, and matching corresponding settlement basic data from the data collection unit; when reaching a settlement period corresponding to the fund accounting unit, calling a general settlement calculator based on a settlement rule expression, calculating the cost of the matched settlement basic data, and generating a settlement cost result under a corresponding fund flow relationship; writing the settlement cost result into a provisional receivable record or a provisional payable record, and storing the fund model definition, the settlement basic data and the settlement rule expression in association with the corresponding record. The application can improve the settlement configuration flexibility, reduce the development cost and enhance the accounting traceability.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method and system for automatically calculating settlement fees based on a capital model definition. Background Technology

[0002] As businesses expand their operations, scenarios such as advertising, supply chain collaboration, external procurement, and revenue sharing typically involve multiple settlement entities. After business delivery, it's crucial to calculate costs such as customer payments, supplier payments, rebates, and service fees based on business data. Existing settlement engines are usually based on pre-defined business type templates, which pre-define settlement participants, cost items, and processes. Business personnel can generally only configure settlement methods, price parameters, or percentage parameters within these pre-defined templates to achieve automatic settlement under fixed business models. For scenarios with mature business models and stable settlement relationships, this approach can meet basic accounting needs.

[0003] However, in scenarios involving new business exploration or project-based collaborations, the business participants, fund flows, expense types, and underlying data upon which settlement relies often change dynamically as the business progresses. New partners or expense items may be added to the same project temporarily, and the same settlement entity may act as the payer or payee in different expense items. Existing settlement engines struggle to customize settlement participants and multiple expense settlement rules without redeveloping business templates, forcing new settlement requirements to rely on manual calculation or custom development. Manual calculation lacks systematic data retention and verification, making it prone to calculation errors and risk control loopholes; custom development, on the other hand, suffers from long development cycles, poor reusability, and difficulty adapting to rapid business adjustments. Summary of the Invention

[0004] In view of this, the embodiments of this application provide an automatic settlement fee calculation method and system based on a capital model definition, in order to solve the problems of difficulty in defining settlement entities, difficulty in expanding fee rules, and lack of system verification in the existing technology.

[0005] A first aspect of this application provides an automatic settlement fee calculation method based on a capital model definition, comprising: acquiring audited and confirmed settlement basic data for a target project, and establishing a searchable data collection unit according to the project identifier and data type; acquiring the capital model definition corresponding to the target project, wherein the capital model definition is used to characterize the capital flow relationship of settlement fees between different settlement entities, and includes fee attributes, settlement entity roles, basic data reference conditions, and settlement rule expressions; according to the capital model definition, parsing each settlement fee into a capital calculation unit containing a payment side, a collection side, a data reference side, and a rule calculation side, and matching the corresponding settlement basic data from the data collection unit according to the basic data reference conditions; when the settlement cycle corresponding to the capital calculation unit is reached, calling a general settlement calculator based on the settlement rule expression to calculate the fees on the matched settlement basic data and generate settlement fee results under the corresponding capital flow relationship; and writing the settlement fee results into the provisional accounts receivable record or provisional accounts payable record according to the attribution relationship between the payment side, the collection side, and the preset settlement entity, and associating and storing the capital model definition, settlement basic data, and settlement rule expressions with the corresponding records.

[0006] A second aspect of this application provides an automatic settlement fee calculation system based on a capital model definition, comprising: an establishment module for acquiring audited and confirmed basic settlement data for a target project and establishing a searchable data collection unit according to the project identifier and data type; an acquisition module for acquiring the capital model definition corresponding to the target project, wherein the capital model definition characterizes the fund flow relationship of settlement fees between different settlement entities and includes fee attributes, settlement entity roles, basic data reference conditions, and settlement rule expressions; and a matching module for parsing each settlement fee into a data type including the payment side, the receiving side, and the data type according to the capital model definition. The system uses the fund accounting unit on the referencing side and the rule calculation side, and matches the corresponding settlement basic data from the data collection unit based on the basic data referencing conditions; the calculation module is used to call the general settlement calculator based on the settlement rule expression when the settlement period corresponding to the fund accounting unit is reached, to calculate the fees of the matched settlement basic data, and generate the settlement fee results under the corresponding fund flow relationship; the writing module is used to write the settlement fee results into the provisional accounts receivable record or provisional accounts payable record according to the attribution relationship between the payment side, the collection side and the preset settlement entity, and associate and store the fund model definition, settlement basic data and settlement rule expression with the corresponding record.

[0007] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: By acquiring the audited and confirmed settlement basic data for the target project and establishing searchable data collection units according to project identifiers and data types; obtaining the capital model definition corresponding to the target project, which represents the capital flow relationship of settlement fees between different settlement entities and includes fee attributes, settlement entity roles, basic data reference conditions, and settlement rule expressions; based on the capital model definition, each settlement fee is parsed into a capital accounting unit containing a payment side, a collection side, a data reference side, and a rule calculation side, and the corresponding settlement basic data is matched from the data collection unit according to the basic data reference conditions; when the settlement cycle corresponding to the capital accounting unit is reached, a general settlement calculator is called based on the settlement rule expression to calculate the fees on the matched settlement basic data and generate the settlement fee results under the corresponding capital flow relationship; according to the attribution relationship between the payment side, the collection side, and the preset settlement entity, the settlement fee results are written into the provisional accounts receivable record or the provisional accounts payable record, and the capital model definition, settlement basic data, and settlement rule expressions are associated and stored with the corresponding records. This application can improve the flexibility of settlement configuration, reduce development costs, and enhance accounting traceability. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a flowchart illustrating the automatic settlement fee calculation method based on a capital model definition provided in this application embodiment; Figure 2 This is a schematic diagram of the structure of the automatic settlement fee calculation system based on the capital model definition provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] In existing technologies, enterprise settlement systems typically employ settlement engines to automate expense calculations. These settlement engines are generally based on pre-defined business type templates, which pre-define business participants, expense items, settlement directions, and settlement processes. When maintaining settlement policies, business personnel can usually only configure parameters such as settlement methods, unit prices, percentages, and tiered ranges within the established templates. For settlement scenarios with mature business models, stable participants, and fixed expense items, this approach can support conventional accounts receivable and accounts payable accounting.

[0012] However, in the trial phase of new businesses or project-based collaborations, the business participants, fund flows, fee types, and the underlying data upon which settlement relies often change as the business progresses. For example, different fee items such as service fees, rebates, and material production fees may be added to the same project, and the same settlement entity may act as the payer or payee under different fee items. Existing settlement engines, due to their reliance on preset business templates, find it difficult to flexibly define settlement entities and their fund flows, and also find it difficult to dynamically expand multiple fee rules under the same project. This results in new settlement requirements needing to rely on manual calculation or the redevelopment of settlement templates, leading to problems such as difficulty in customizing settlement entities, difficulty in expanding fee rules, and a lack of system verification in calculations.

[0013] To address the aforementioned issues, this application proposes an automatic settlement fee calculation method based on a capital model definition, which abstracts the settlement relationships under a project into a capital model definition. This capital model definition characterizes the fund flow relationship of a settlement fee between different settlement entities and associates and configures fee attributes, settlement entity roles, basic data reference conditions, and settlement rule expressions. After obtaining the verified settlement basic data for the target project, the system establishes searchable data collection units according to project identifiers and data types; then, based on the capital model definition corresponding to the target project, it parses each settlement fee into a capital accounting unit containing a payment side, a collection side, a data reference side, and a rule calculation side.

[0014] During the specific accounting process, the system matches the corresponding settlement basic data from the data collection unit based on the basic data reference conditions in the fund accounting unit. Upon reaching the settlement cycle, it calls the general settlement calculator based on the settlement rule expression to perform cost calculations and generate settlement cost results under the corresponding fund flow relationship. Subsequently, based on the attribution relationship between the payer, the payee, and the preset settlement entity, the system automatically writes the settlement cost results into the provisional accounts receivable or provisional accounts payable record, and associates and stores the fund model definition, settlement basic data, settlement rule expression, and calculation process data with the corresponding records.

[0015] Therefore, this application no longer relies on fixed business type templates to limit settlement participants and expense items. Instead, it uses a project-level funding model to define the configurable combination of settlement entities, fund flows, basic data, and settlement rules. This technical solution improves the flexibility of settlement configuration, reduces development costs for new business scenarios, and enhances the system's verification capabilities and traceability of settlement expense calculation results.

[0016] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0017] Figure 1 This is a flowchart illustrating the automatic settlement fee calculation method based on a capital model definition provided in this application embodiment. Figure 1 As shown, the method may specifically include: S101, Obtain the audited and confirmed basic settlement data under the target project, and establish a searchable data collection unit according to the project identifier and data type; S102, Obtain the capital model definition corresponding to the target project. The capital model definition is used to represent the capital flow relationship between settlement fees and different settlement entities, and includes fee attributes, settlement entity roles, basic data reference conditions and settlement rule expressions. S103, according to the definition of the capital model, each settlement fee is parsed into a capital accounting unit that includes the payment side, the collection side, the data reference side and the rule calculation side, and the corresponding settlement basic data is matched from the data collection unit according to the basic data reference conditions; S104, When the settlement period corresponding to the fund accounting unit is reached, the general settlement calculator is called based on the settlement rule expression to calculate the fees of the matched settlement basic data and generate the settlement fee results under the corresponding fund flow relationship; S105: Based on the attribution relationship between the payer, the receiver, and the preset settlement entity, write the settlement fee results into the provisional accounts receivable record or provisional accounts payable record, and associate and store the capital model definition, settlement basic data, and settlement rule expression with the corresponding record.

[0018] In some embodiments, the process involves acquiring audited and confirmed settlement data for the target project and establishing a searchable data collection unit based on the project identifier and data type, including: Receive business settlement data associated with the target project and configure the corresponding data access identifier according to the data source method; Perform project attribution verification and data type identification on business settlement data, and generate data records to be reviewed carrying project identifier, data type identifier, and source identifier; Once the data records to be audited meet the preset audit conditions, the data records to be audited are converted into settlement basic data and written into the corresponding data collection unit according to the project identifier and data type identifier; Establish retrieval indexes for data collection units that match the basic data reference conditions defined in the funding model.

[0019] Specifically, after a project is approved, the settlement system first generates a unique project identifier for the target project and maintains a list of data types and data sources that can participate in the settlement within the project data. Taking an automotive advertising project as an example, the project needs to calculate customer placement costs, media recharge costs, external procurement and operation service fees, customer service fees, customer return fees, and material production costs. Therefore, the system configures account consumption data, account recharge data, lead conversion data, and material production data as available data types, and records the field definition, statistical period, upload responsibility party, and review responsibility party for each type of data.

[0020] During business execution, settlement data can be accessed via API or uploaded manually by business personnel. For data such as cash consumption and media recharge records for advertising accounts, the system can automatically retrieve data from the advertising platform or financial system according to project identifiers and configure system API access identifiers. For lead conversion details provided by external procurement service providers and material production details provided by material service providers, business personnel can select the corresponding project and data type in the settlement system and upload the detailed files, with the system configured with a manual upload access identifier. Data access identifiers are used to distinguish data source methods, access times, access personnel, or API sources, facilitating subsequent review and traceability.

[0021] After receiving business settlement data, the system performs project attribution verification and data type identification. Project attribution verification compares the data against the project identifier selected during upload, the project code carried in the interface data, the contract number, the advertising account number, or the partner number to confirm that the business settlement data belongs to the target project. Data type identification determines the data type based on the user-selected data type, file template, field name, field format, and data content.

[0022] For example, if the data contains fields such as account number, date, cash consumption, and rebate percentage, it is identified as account consumption data; if the data contains fields such as recharge date, recharge account, and recharge amount, it is identified as account recharge data; if the data contains fields such as the number of valid leads or the number of materials accepted, it is identified as lead conversion data or material production data. After identification, the system generates a data record to be reviewed, and writes the project identifier, data type identifier, source identifier, settlement period, data batch, and original file fingerprint into the record.

[0023] Once data records awaiting review enter the financial or business review process, the system verifies them according to preset review criteria. These criteria may include: complete data fields; consistent project attribution; statistical period not exceeding the project's validity period; valid key amounts or quantities; no duplicate entries within the same batch; unaltered source files; and confirmation by responsible personnel. For data accessed via API, the system can use API feedback results, synchronization logs, and field validation results as review criteria. For manually uploaded data, the system can use uploaded files, template validation results, business confirmation opinions, and financial review opinions as review criteria. Data that fails review remains in a pending state, with the reason for the anomaly recorded, and is not allowed to proceed to settlement calculations.

[0024] Furthermore, once the data record to be reviewed meets the preset review conditions, the system converts the data record into settlement basic data and writes it into the corresponding data collection unit according to the project identifier and data type identifier. The data collection unit can be partitioned and stored according to project, data type, and settlement period. For example, the account consumption data generated by the car advertising campaign in August 2024 is written into the account consumption data collection unit corresponding to that project; the material production quantity data uploaded and approved by Company D during the same period is written into the material production quantity data collection unit corresponding to that project. During the writing process, the system retains the original data, standardized fields, review status, source identifier, and batch information, enabling different expense items under the same project to share the same type of settlement basic data.

[0025] To facilitate automatic data retrieval for the capital model definition, the system further establishes retrieval indexes for data collection units. These indexes are generated based on project identifiers, data type identifiers, settlement periods, audit status, and data batches, and maintain consistency with the basic data reference conditions defined in the capital model. For example, customer placement fees, customer service fees, and customer rebates all reference account consumption data; the system quickly locates audited cash consumption data using the same data type identifier and period index. Similarly, material production fees reference material production quantity data; the system locates the corresponding acceptance quantity for Company D using the material quantity data index. Through these processes, the settlement system can directly retrieve reliable data based on the capital model definition during expense accounting, improving the efficiency of settlement data collection, the accuracy of accounting, and data traceability.

[0026] In some embodiments, obtaining the funding model definition corresponding to the target project includes: In response to a funding model configuration request for a target project, obtain the funding flow configuration, data reference configuration, and rule calculation configuration associated with settlement fees; The settlement entity role relationship corresponding to the settlement fee is determined based on the fund flow configuration, and the fund flow relationship between the payer and the receiver is generated. The basic data reference conditions that are compatible with the settlement fees are determined based on the data reference configuration, and the corresponding settlement rule expression is generated based on the rule calculation configuration. The system performs integrity checks and validity checks on the fund flow relationships, basic data reference conditions, and settlement rule expressions. After the checks pass, it generates a fund model definition associated with the target project.

[0027] Specifically, after a target project is approved, the settlement system opens a funding model configuration page to business personnel with configuration permissions. These personnel can then initiate a funding model configuration request for the automotive advertising project. The system retrieves information on the maintained settlement entities, including clients, our company, media suppliers, external procurement and operation service providers, and material service providers, based on the project identifier. It also retrieves a list of data types that have been approved or are awaiting integration, as well as a general settlement rule library, forming a set of basic information available for configuration. On the page, configuration personnel select the settlement fees to be added or maintained and enter the fund flow configuration, data reference configuration, and rule calculation configuration, ensuring that each fee can be described as an independent funding model rule.

[0028] During the fund flow configuration process, the system no longer relies on fixed business type templates with pre-defined settlement parties. Instead, it generates settlement entity role relationships based on the payment entity, collection entity, and corresponding roles selected by the business personnel. For example, customer advertising fees correspond to Company A as the payment side and XX Technology Company as the collection side, with Company A representing the customer and XX Technology Company representing our company; media recharge fees correspond to XX Technology Company as the payment side and Company B as the collection side, with Company B representing the media supplier; and external procurement operation service fees correspond to XX Technology Company as the payment side and Company C as the collection side, with Company C representing the external procurement operation service provider.

[0029] In some examples, for subsequent new customer service fees, customer rebates, and material production costs, the system also generates new payment and collection relationships through configuration requests. In the latter case, the flow of funds for customer rebates is opposite to that of customer advertising costs, with the payment side being XX Technology Company and the collection side being Company A. This shows that the same customer entity can have different payment and collection directions in different expense items.

[0030] During the data reference configuration process, the system generates basic data reference conditions based on the settlement fee, the corresponding basic data type, the data retrieval period, the review status requirements, and the project affiliation conditions. For example, customer campaign fees, customer service fees, and customer return fees all reference account consumption data. The system combines the project identifier, account consumption data type, monthly settlement period, and review approval status into data retrieval conditions; media recharge fees reference account recharge data; external procurement operation service fees reference car lead conversion quantity data; and material production fees reference material quantity data. Through this configuration method, newly added fee items can reuse data types already collected under the project, or reference newly integrated and approved data types, avoiding the need to redevelop dedicated data reading logic.

[0031] During the rule calculation configuration process, the system generates settlement rule expressions based on the billing method and configuration parameters selected by the business personnel. For fixed percentage fees, the system binds the cash consumption field to the percentage parameter to form a rule expression used to calculate customer service fees or customer rebates; for fixed unit price fees, the system binds the recharge amount, material quantity, or other measurement fields to the unit price parameter; for tiered fees, the system binds the lead conversion quantity field to the tiered range and range price to form a rule expression that can be recognized by a general settlement calculator. These rule expressions are not embedded in the project code but are stored as a component of the funding model definition, enabling different expense items to share the ability to execute general rules.

[0032] After the fund flow relationship, basic data reference conditions, and settlement rule expressions are generated, the system performs integrity checks and effectiveness condition checks. Integrity checks determine if the payment side, collection side, expense attributes, data reference conditions, and rule calculation parameters are complete, and whether the payment side and collection side are valid project participants. Effective condition checks determine if the effective period of the fund model rule covers the target settlement period, if the referenced data type is enabled under the project, if the rule parameters meet the pre-designed fee scope, and if there are conflicting versions of the same expense item. If the checks find that the customer has not configured the proportion parameters, or that the data type referenced for material production costs is not yet enabled, the system will set the rule to a pending completion status and prompt for correction, preventing it from entering the automatic calculation process.

[0033] Furthermore, once the verification is successful, the system generates a funding model definition associated with the target project and configures the version number, activation status, and effective period for the funding model definition. For automotive advertising projects, the basic funding model definition can be formed by referring to the customer placement fees, media recharge fees, and external procurement operation service fees in Table 1 below. The customer service fees, customer rebates, and material production fees in Table 2 can be added to the same project as supplementary rules after business changes.

[0034] Table 1. Definition of Basic Funding Model

[0035] Table 2. Basic Capital Model Definition Table After Adding Rules

[0036] Through the above implementation methods, the settlement system can transform new settlement participants, new expense items, and new calculation rules into capital model configuration results, improving the efficiency of settlement rule expansion during the business trial period and reducing template development costs. In some embodiments, basic data reference conditions adapted to settlement fees are determined based on data reference configuration, and corresponding settlement rule expressions are generated based on rule calculation configuration, including: Parse the data retrieval constraints in the data reference configuration corresponding to settlement fees, and determine the basic data reference conditions used to limit project ownership, data type, and settlement period; Based on the basic data reference conditions, the value fields involved in the cost calculation are determined from the preset data field mapping relationship, and data variables associated with the settlement cost are generated; The parsing rules calculate the billing logic and billing parameters configured in the configuration, write the data variables and billing parameters into the preset rule template, and generate the settlement rule expression; Perform consistency checks on the data variables in the settlement rule expression and the basic data reference conditions.

[0037] Specifically, after a target project enters the funding model configuration phase, the settlement system first reads the project information, enabled data types, data field mapping relationships, and rule template library, and then loads the corresponding configuration items based on the settlement fees selected by the configuration personnel. Taking an automotive advertising project as an example, customer placement fees, customer service fees, and customer rebates all need to be calculated based on the advertising account's consumption; media recharge fees need to be calculated based on recharge transaction volume; external procurement and operation service fees need to be calculated based on the number of valid lead conversions; and material production fees need to be calculated based on the number of accepted materials. The system receives data reference configurations and rule calculation configurations for each fee item, ensuring that the fee data retrieval scope and calculation scope are bound together within the same funding model rules.

[0038] When parsing data reference configurations, the system extracts project attribution conditions, data type conditions, settlement period conditions, and data status conditions from the configuration content to form basic data reference conditions. Project attribution conditions limit data to the current automotive advertising campaign, preventing misuse of advertising account data, recharge data, or creative data from other projects. Data type conditions limit the data collection units that can be referenced for the current fee; for example, customer service fees can only reference account consumption data, and creative production fees can only reference creative quantity data. Settlement period conditions limit the data retrieval range to be consistent with monthly, quarterly, or other settlement cycles. Data status conditions limit the retrieval of only approved and not invalidated data. Through these constraints, the system transforms the data retrieval requirements configured by business personnel into executable search conditions.

[0039] Furthermore, after determining the basic data reference conditions, the system identifies the value fields involved in cost calculation based on preset data field mapping relationships. Field mapping relationships are used to record the correspondence between standard fields and calculation variables under different data types. For example, the cash consumption field in account consumption data is mapped to the consumption amount variable, the recharge amount field in account recharge data is mapped to the recharge amount variable, the valid lead number field in lead conversion quantity data is mapped to the lead quantity variable, and the acceptance quantity field in material quantity data is mapped to the material quantity variable. For the same type of account consumption data, the system can simultaneously generate data variables corresponding to different costs for customer campaign expenses, customer service fees, and customer return payments, enabling the same basic data to serve accounting for different fund flows and different cost attributes.

[0040] When parsing the rule calculation configuration, the system identifies the billing logic and billing parameters, and writes the data variables into a preset rule template. If the settlement fee adopts proportional billing, the system writes the consumption amount variable and the proportional parameter into the proportional calculation template. For example, customer service fee can be configured as consumption amount multiplied by service fee percentage, and customer rebate can be configured as consumption amount multiplied by rebate percentage. If the settlement fee adopts unit price billing, the system writes the quantity variable or amount variable and the unit price parameter into the unit price calculation template. For example, material production fee can be configured as material quantity multiplied by material unit price. If the settlement fee adopts tiered billing, the system writes the lead quantity variable, tier range, and range price into the tiered calculation template. For example, external procurement operation service fee can be matched with the corresponding unit price according to the range in which the number of valid leads falls. The settlement rule expression generated by the system adopts a structured expression form that can be recognized by a general settlement calculator, and is associated with and saved with the fee identifier, version number, and effective period.

[0041] Furthermore, after the settlement rule expression is generated, the system performs a consistency check on the data variables in the expression and the basic data reference conditions. The check includes whether the data variable source belongs to the data type limited by the basic data reference conditions, whether the variable field exists in the corresponding data collection unit, whether the billing parameters are complete, whether the rule template supports the current billing logic, and whether the settlement period falls within the effective period of the funding model.

[0042] For example, if the customer's return expression references a material quantity variable, the system determines that the variable source is inconsistent with the account consumption data reference conditions; if the tiered billing is not configured with a complete range or range price, the system determines that the rule calculation configuration is incomplete. When the verification fails, the system marks the capital model rule as pending correction and does not allow it to enter the automatic calculation process; after the verification passes, the system writes the basic data reference conditions, data variables, and settlement rule expressions into the capital model definition of the target project.

[0043] The above implementation method ensures that the data retrieval conditions and calculation rules for new expense items can be configured in a structured manner without the need to develop a dedicated template, thereby improving the efficiency of settlement rule expansion and reducing data retrieval errors and manual calculation deviations.

[0044] In some embodiments, according to the funding model definition, each settlement fee is parsed into a funding accounting unit comprising a payment side, a collection side, a data reference side, and a rule calculation side, including: Read the expense attributes and fund flow relationships corresponding to the target settlement expense in the fund model definition to determine the payment side and collection side of the target settlement expense under the target project; Based on the settlement entity roles associated with the payment side and the collection side, the direction consistency of the fund flow relationship is verified; Bind the basic data reference conditions to the data reference side of the target settlement fee, and bind the settlement rule expression to the rule calculation side of the target settlement fee; After verification, a fund accounting unit is generated, carrying project identifier, cost attributes, fund flow relationship, basic data reference conditions and settlement rule expression, so that the target settlement cost can participate in subsequent cost calculation as an independent and executable settlement object.

[0045] Specifically, before the settlement system enters its periodic accounting tasks, the system reads the existing funding model definitions according to the target project and breaks down the funding model rules at the granularity of fee identifiers. Taking an automotive advertising project as an example, the funding model definition includes multiple settlement fees such as customer placement fees, media recharge fees, external procurement and operation service fees, customer service fees, customer rebates, and material production fees. The system reads the fee attributes and fund flow relationships one by one. The fee attributes are used to indicate whether the fee belongs to the business category of placement settlement, recharge settlement, service settlement, rebate settlement, or production settlement, while the fund flow relationships are used to indicate the payment and receipt directions of the fee among the project participants.

[0046] For client advertising costs, the system identifies the cost attribute as client advertising settlement from the funding model definition. The payment side is Company A, and the receiving side is XX Technology Company. Company A is associated with the client role, and XX Technology Company is associated with our company's main role. For media recharge costs, the payment side is XX Technology Company, and the receiving side is Company B. Company B is associated with the media supplier role. For external procurement and operation service fees, the payment side is XX Technology Company, and the receiving side is Company C. Company C is associated with the external procurement and operation service provider role. For customer rebates, the payment side is XX Technology Company, and the receiving side is Company A. Since Company A is the payment side in client advertising costs but the receiving side in customer rebates, the system distinguishes the payment and receipt identities of the same settlement entity under different cost items through cost attributes and fund flow relationships, avoiding the need to determine the payment and receipt direction solely based on the entity's identity.

[0047] Furthermore, after determining the payment and collection sides, the system performs a direction consistency check based on the associated settlement entity roles on both sides. This direction consistency check does not require a specific entity to only make payments or receive payments in a fixed manner; rather, it verifies whether the current expense attributes and configured fund flows align with the project settlement relationship. For example, customer placement fees and customer service fees should be paid from the customer side to our entity; customer rebates should be paid from our entity to the customer side; and media recharge fees and material production fees should be paid from our entity to the corresponding supplier. If the configuration personnel mistakenly set customer rebates to be paid by Company A to XX Technology Company, the system identifies this as an abnormal configuration direction based on the direction constraints of rebate-type expenses, marks the fund model rule as unexecutable, and prompts a reconfirmation of the payment and collection sides.

[0048] Furthermore, after the direction consistency verification passes, the system binds the basic data reference conditions to the data reference side of the target settlement fee. Customer placement fees, customer service fees, and customer rebates are all bound to account consumption data reference conditions, which include the project identifier, account consumption data type, settlement period, and approval status. Media recharge fees are bound to account recharge data reference conditions, external procurement operation service fees are bound to automotive lead conversion quantity data reference conditions, and material production fees are bound to material quantity data reference conditions. Through this binding method, the same type of settlement basic data can be reused by multiple fee items, but each fee item still has an independent data reference side, allowing for independent data retrieval, verification, and traceability during subsequent accounting.

[0049] Simultaneously, the system binds settlement rule expressions to the rule calculation side of the target settlement fee. Customer campaign costs can be bound to rule expressions formed by cash consumption and rebate deduction parameters; customer service fees can be bound to rule expressions formed by cash consumption and service fee ratios; customer rebates can be bound to rule expressions formed by cash consumption and rebate ratios; material production costs can be bound to rule expressions formed by material quantity and unit price; and external procurement operation service fees can be bound to rule expressions formed by lead quantity and tiered pricing. The rule calculation side only stores structured expressions that can be executed by a general settlement calculator, eliminating the need to develop dedicated calculation programs for new fees.

[0050] After binding the payment side, collection side, data reference side, and rule calculation side, the system generates a fund accounting unit. Each fund accounting unit carries a project identifier, expense attributes, fund flow relationship, basic data reference conditions, settlement rule expression, version number, and effective period, and is written into the periodic accounting task queue. Each fund accounting unit participates in subsequent expense calculations as an independent, executable settlement object. For example, although customer service fees and customer rebates both reference account consumption data, due to differences in fund flow relationships and rule calculation sides, the system will generate separate accounting results for accounts receivable and accounts payable. Similarly, material production costs, as a new expense item, can directly enter the general calculation process using an independent fund accounting unit.

[0051] Through the above implementation method, settlement fees no longer rely on pre-set settlement participants and fee items in fixed business templates, but are parsed into fund accounting units with complete payment and receipt directions, data retrieval standards, and calculation logic. This processing method can improve the project-level fee expansion capability, reduce the development cost of new business settlements, and make each provisional receivable or provisional payable traceable to the corresponding fund model rules.

[0052] In some embodiments, matching the corresponding settlement base data from the data collection unit based on the base data reference conditions includes: Analyze the basic data reference conditions carried in the fund accounting unit to determine the data retrieval range corresponding to the target project, data type, settlement period and expense attribute; Based on the data range, perform index retrieval in the data collection unit to filter candidate settlement basic data that are consistent with the target project and data type; The candidate settlement data is audited for status, validity during the period, and status of repeated references. Data records that do not meet the accounting conditions are removed. Establish a reference binding relationship between the verified candidate settlement basic data and the fund accounting unit to generate a set of settlement basic data that can be called by the rule calculation side.

[0053] Specifically, after a periodic settlement task is initiated, the settlement system first reads the fund accounting unit from the pending task queue of the target project and parses the basic data reference conditions carried within it. Taking the car advertising placement project as an example, the fund accounting units for customer placement fees, customer service fees, and customer rebates all carry account consumption data reference conditions, the external procurement operation service fee carries lead conversion quantity data reference conditions, and the material production fee carries material quantity data reference conditions.

[0054] The system determines the data retrieval range for this expense calculation based on the project identifier, data type identifier, settlement period, expense attribute, and review status requirements. For example, during the August 2024 monthly settlement, the data retrieval range for customer service fees is limited to the account consumption data approved for the project between August 1st and August 31st, and the data retrieval range for material production fees is limited to the quantity of materials submitted and approved by the material service provider for the project during the same period.

[0055] Furthermore, after determining the data retrieval range, the system invokes the retrieval index of the data collection unit to execute the query. The data collection unit establishes a combined index based on project identifier, data type identifier, period identifier, and review status. Therefore, the system can first locate the target project and then enter the corresponding data type partition to retrieve candidate settlement basic data. For account consumption data, candidate data may include advertising account number, placement date, cash consumption, rebate parameters, data batch, and source identifier; for lead conversion quantity data, candidate data may include lead source, number of valid leads, conversion confirmation date, and review batch; for creative quantity data, candidate data may include creative number, acceptance date, acceptance quantity, and upload source. Through index retrieval, the system only filters data records that are consistent with the current target project and current data type, avoiding the misuse of other projects, other data types, or uncollected data as the basis for calculation.

[0056] Furthermore, after the candidate settlement data is screened, the system performs pre-calculation verification. The audit status verification confirms that the data has completed business confirmation and financial audit and is in a calculable state; the period validity verification determines whether the data occurrence date, statistical date, or acceptance date falls within the settlement period corresponding to the current fund accounting unit; and the duplicate reference status verification determines whether the same batch of data has already been referenced and calculated by a fund accounting unit with the same expense attribute.

[0057] For example, both client campaign costs and client service fees can reference the same batch of account consumption data. However, due to the different fee attributes, the system allows separate referencing relationships. If the same client service fee accounting unit repeatedly references the same batch of August account consumption data, the system will identify the latter reference as a duplicate and remove it. For manually uploaded material quantity data, if the same material number appears twice in the same settlement period, the system will compare the data batch, file fingerprint, and acceptance confirmation status, and exclude unconfirmed or duplicate submission records.

[0058] During the verification process, the system can also set additional filtering conditions based on cost attributes. For example, for external procurement operation service fees, only the number of confirmed valid leads is retained, excluding invalid leads, leads awaiting review, or overdue confirmed leads; for customer rebates, only cash consumption data that conforms to the rebate period and rebate caliber is used, excluding refunded or cancelled consumption; for media recharge fees, only recharge records that have actually been received and match the media account are used. Data records that fail any verification will be marked as unaccountable data, and the reason for removal, verification time, and verification rules will be retained for subsequent review by business personnel.

[0059] Furthermore, once all candidate settlement basic data passes verification, the system establishes a reference binding relationship between the data records and the corresponding fund accounting units. This binding relationship includes the fund accounting unit identifier, settlement basic data batch, field mapping version, reference period, and reference status, generating a set of settlement basic data that can be accessed by the rule calculation side. For example, after the customer rebate fund accounting unit obtains the August account consumption data set, the rule calculation side can directly read the cash consumption field and rebate ratio parameter to perform calculations; similarly, after the material production cost fund accounting unit obtains the material quantity data set, the rule calculation side can read the acceptance quantity field and unit price parameter to perform calculations.

[0060] Through the above implementation methods, the system can maintain clear reference boundaries when multiple expense items reuse similar basic data, reduce the costs of incorrect data retrieval, duplicate accounting, and manual verification, and improve the accuracy of expense accounting and the traceability of settlement results.

[0061] In some embodiments, a general settlement calculator is invoked based on a settlement rule expression to calculate fees on the matched settlement baseline data, generating settlement fee results under the corresponding fund flow relationship, including: Parse the settlement rule expression to determine the calculation rule type, value fields, and calculation parameters corresponding to the fund accounting unit; Match the corresponding rule execution component from the general settlement calculator based on the calculation rule type, and map the value fields to the matched settlement basic data; Based on the calculation parameters and the mapped settlement basis data, the cost accounting is performed to obtain the calculated value of each individual cost item. The calculated values ​​of individual expenses are summarized and verified according to the fund flow relationship, and a settlement expense result is generated, which includes expense attributes, payment side, collection side and calculation basis.

[0062] Specifically, after the settlement period for the target project arrives, the settlement system reads the completed data-bound fund accounting units from the periodic accounting task queue and parses the settlement rule expressions stored in the fund accounting units. Taking the August 2024 monthly settlement of the car advertising placement project as an example, the system sequentially reads the rule expressions corresponding to customer placement fees, customer service fees, customer rebates, media recharge fees, external procurement operation service fees, and material production fees, and identifies the calculation rule type, value fields, and calculation parameters from the expressions. The calculation rule type is used to determine whether the current fee uses a common calculation method such as proportional calculation, unit price calculation, tiered calculation, or deduction calculation; the value fields are used to determine the business values ​​that need to be read from the settlement basic data set; the calculation parameters are used to carry cost accounting conditions such as proportion, unit price, tiered range, deduction coefficient, rounding rules, and precision rules.

[0063] For example, the rule expression for customer campaign fees can be parsed as a deduction-type calculation rule, with the value field being the cash consumption field in the account consumption data. The calculation parameters include the customer rebate percentage and the amount precision rule. Based on this, the system calculates the campaign fees that Company A should pay to our entity. The rule expression for customer service fees can be parsed as a percentage-type calculation rule, with the value field also coming from the cash consumption field in the account consumption data. The calculation parameter is the service fee percentage. Based on this, the system calculates the service fee that Company A should pay to our entity. The rule expression for customer rebates can also reference account consumption data, but the calculation parameter is the rebate percentage, and the fund flow is our entity paying Company A. Therefore, the same basic dataset can be called by different fund accounting units, resulting in different fee outcomes based on different fund flows and rule parameters.

[0064] During the rule execution phase, the system queries the component registration information of the general settlement calculator based on the calculation rule type. The general settlement calculator pre-registers multiple types of rule execution components. Each component only processes standardized calculation inputs of its corresponding type and is not bound to specific business templates. If the calculation rule type is a proportional calculation, the system matches a proportional rule execution component; if it's a unit price calculation, the system matches a unit price rule execution component; if it's a tiered calculation, the system matches a tiered rule execution component; and if it's a deduction calculation, the system matches a deduction rule execution component. After matching, the system maps the value fields to the settlement basic data set according to the field mapping relationship. For example, the value field of the material production fee is mapped to the acceptance quantity field in the material quantity data; the value field of the media recharge fee is mapped to the recharge amount field in the account recharge data; and the value field of the external procurement operation service fee is mapped to the valid lead number field in the lead conversion quantity data.

[0065] Furthermore, after the field mapping is completed, the system performs format conversion and accounting treatment on the mapped values. Amount fields are uniformly converted to monetary values ​​in the settlement currency, quantity fields are uniformly converted to measurable values ​​for calculation, and ratio parameters are uniformly converted to decimal form. Tiered intervals are sorted and their boundaries are validated according to the effective version. For external procurement operation service fees, if the number of valid leads in August is 350, the system matches the corresponding interval according to the tiered rule execution component and calculates the fee according to the interval price configured in the rule. For material production fees, if Company D approves 80 materials in the current month, the system inputs the material quantity and unit price into the unit price rule execution component to obtain the material production fee. For customer rebates, the system inputs the cash consumption and rebate ratio into the ratio rule execution component to obtain the rebate amount.

[0066] When the system performs cost accounting, it first generates detailed calculated values ​​for each basic settlement data item, and then summarizes them according to the cost attributes and fund flow relationships of the fund accounting unit. The summary verification includes ensuring the calculated detailed total matches the total cost, that the amount precision meets the configuration, that negative or outlier values ​​meet the rule restrictions, and that the same data batch is not repeatedly charged for the same cost. For cases where customer service fees and customer rebates share account consumption data, the system distinguishes the calculation results based on cost attributes and does not offset the two costs against each other. For cases where customer payment fees and customer rebate funds have opposite directions, the system generates corresponding cost results separately for the payment side and the receiving side. If a rule execution component returns an exception, the system records the exception fields, the exception data batch, and the exception rule version, and suspends the generation of results for that fund accounting unit.

[0067] Furthermore, after the summary verification is passed, the system generates settlement fee results. The settlement fee results include the project identifier, fee attribute, payment side, receiving side, settlement period, settlement amount, and calculation basis. The calculation basis includes the fund accounting unit identifier, settlement rule expression version, data batches involved in the calculation, field mapping results, and detailed calculation process. For example, the customer service fee result indicates that Company A paid a service fee to our entity; the customer return result indicates that our entity paid a return payment to Company A; and the material production fee result indicates that our entity paid material production fees to Company D.

[0068] Through the above implementation methods, the settlement system can reuse the general settlement calculator when adding new expense items and new settlement entities, reducing the development of dedicated templates and improving the accuracy, verifiability and traceability of expense calculation results.

[0069] In some embodiments, matching a corresponding rule execution component from a general settlement calculator based on the calculation rule type, and mapping the value fields to the matched settlement base data, includes: Based on the calculation rule type, query the rule component registration information in the general settlement calculator to determine the rule execution component that matches the settlement rule expression; The input field requirements and value fields of the rule execution component are matched and validated to generate a field mapping relationship; Based on the field mapping relationship, the corresponding field values ​​are extracted from the matched settlement basic data, and the field values ​​are converted in terms of data format and accounting caliber. The transformed field values, calculation parameters, and fund flow relationships are encapsulated into standardized calculation inputs and sent to the rule execution component.

[0070] Specifically, after a target project enters the cost calculation stage, the settlement system first reads the settlement rule expression in the fund accounting unit and identifies the calculation rule type from the expression header or rule metadata. Taking an automotive advertising project as an example, customer service fees and customer rebates correspond to proportional calculation types, material production fees and media recharge fees correspond to unit price calculation types, external procurement operation service fees correspond to tiered calculation types, and customer placement fees correspond to deduction calculation types with rebates. The system uses the identified calculation rule type as a component addressing condition to query the rule component registration information in the general settlement calculator. The rule component registration information includes component identifier, applicable rule type, input field requirements, parameter format, precision rules, and exception return method. Through this registration information, the settlement system can match executable rule execution components for different cost items without distinguishing specific business templates.

[0071] During component matching, the system first checks if a registered component exists for the rule type in the settlement rule expression, and then checks if the parameter structure carried by the rule expression meets the component call requirements. For example, the proportional rule execution component requires input of an amount variable and a proportional parameter; the unit price rule execution component requires input of a quantity or amount variable and a unit price parameter; the tiered rule execution component requires input of a quantity variable, a tiered range, and a range price; and the deduction rule execution component requires input of a base amount and a deduction parameter.

[0072] In some examples, if the customer return rule expression includes a consumption amount variable and a return percentage, the system matches the percentage rule execution component; if the material production cost includes a material quantity variable and a material unit price, the system matches the unit price rule execution component; if the external procurement operation service fee includes a valid lead quantity and a tiered pricing table, the system matches the tiered rule execution component. If the expression lacks necessary parameters, the system sets the fund accounting unit to a rule exception state.

[0073] Furthermore, after matching the rule execution component, the system performs a matching and validation of the component's input field requirements and value fields, generating a field mapping relationship. This field mapping relationship specifies from which type of settlement base data and which standard field the standard input fields required by the rule execution component should be obtained. For example, in customer service fees, the percentage rule execution component requires an amount input field, which the system maps to the cash consumption field in the account consumption data; customer return also maps to the cash consumption field, but the calculation parameters and fund flow are different; in material production fees, the unit price rule execution component requires a quantity input field, which the system maps to the acceptance quantity field in the material quantity data; in media recharge fees, the unit price or amount rule execution component maps to the recharge amount field in the account recharge data; in external procurement operation service fees, the tiered rule execution component maps to the effective lead number segment in the lead conversion quantity data. After the field mapping relationship is generated, the system records the mapping version to avoid subsequent adjustments to field definitions affecting the traceability of already generated fee results.

[0074] Subsequently, the system extracts the corresponding field values ​​from the matched settlement base data set based on the field mapping relationship, and performs data format and accounting caliber conversion. The amount field is converted to a unified settlement currency and amount precision, the quantity field is converted to a unified unit of measurement, the proportion parameter is converted to a decimal for calculation, and the date field is converted to a recognizable time boundary within the settlement period. For account consumption data accessed via the API, the system can summarize the cash consumption of different advertising accounts by project caliber; for manually uploaded material quantity data, the system can summarize the number of accepted materials by material service provider and settlement period; for lead conversion quantity data, the system only extracts the number of confirmed valid leads that have not been repeatedly billed. If a field value is empty, has an incorrect format, or the caliber is inconsistent, the system records the abnormal data batch and blocks the corresponding details from participating in the calculation.

[0075] Furthermore, after completing field extraction and caliber conversion, the system encapsulates the converted field values, calculation parameters, and fund flow relationships into standardized calculation inputs. These standardized calculation inputs include the fund accounting unit identifier, rule execution component identifier, expense attributes, payment side, collection side, settlement period, input field values, parameter values, precision rules, and data source batches. For example, the standardized calculation input for customer service fees includes the fund flow from Company A to XX Technology Company, the amount of cash consumed, and the service fee ratio; the standardized calculation input for customer rebates includes the fund flow from XX Technology Company to Company A, the amount of cash consumed, and the rebate ratio; and the standardized calculation input for material production fees includes the fund flow from XX Technology Company to Company D, the quantity of materials received, and the unit price of the materials. The rule execution component only receives this standardized input and returns the calculation results, without needing to be aware of the specific business template or the source of any new expense items.

[0076] Through the above implementation methods, the general-purpose settlement calculator can automatically match components based on rule component registration information, convert basic data values ​​based on field mapping relationships, and perform cost accounting based on standardized calculation inputs. This processing method allows new costs such as customer service fees, customer rebates, and material production costs to participate in automatic settlement without the need to develop dedicated calculation programs, improving rule reusability and cost calculation stability, while ensuring that the source of fields, parameter definitions, and fund flows are all traceable.

[0077] In some embodiments, the settlement fee results are written to the provisional accounts receivable record or provisional accounts payable record, and the funding model definition, settlement basis data, and settlement rule expression are associated and stored with the corresponding records, including: Based on the attribution relationship between the payer, the receiver, and the pre-set settlement entity, determine the payment / receipt direction identifier corresponding to the settlement fee result; When the payment direction indicator indicates that the preset settlement entity is the payee, a provisional accounts receivable record is generated; when the payment direction indicator indicates that the preset settlement entity is the payee, a provisional accounts payable record is generated. Write the settlement fee results to the corresponding record and configure the corresponding record with a pending confirmation status; Establish a traceability relationship between the capital model definition, settlement basis data, settlement rule expressions, and calculation process data on which the settlement fee results are based and the corresponding records.

[0078] Specifically, after the target project completes its cost calculation, the settlement system reads the settlement cost results output by each fund accounting unit and determines the payment / receipt direction identifier based on the pre-configured settlement entity of our company for the project. Taking a car advertising placement project as an example, the preset settlement entity in the project is XX Technology Company. The system compares the attribution relationship between the payment side, the collection side, and XX Technology Company in the settlement cost results. If the collection side is XX Technology Company, the system identifies the cost result as receivable; if the payment side is XX Technology Company, the system identifies the cost result as payable. Through this judgment method, the system does not directly determine receivable or payable based on the cost name, but rather based on the actual fund flow formed in the fund model definition, avoiding direction errors when the same settlement entity changes its payment / receipt identity in different cost items.

[0079] For example, customer placement fees correspond to payments from Company A to XX Technology Company, and customer service fees also correspond to payments from Company A to XX Technology Company. The system configures these two fee results as accounts receivable direction identifiers and generates provisional accounts receivable records for each. Customer rebates correspond to payments from XX Technology Company to Company A, media recharge fees correspond to payments from XX Technology Company to Company B, external procurement and operation service fees correspond to payments from XX Technology Company to Company C, and material production fees correspond to payments from XX Technology Company to Company D. The system configures these fee results as accounts payable direction identifiers and generates provisional accounts payable records for each. When customer rebates and customer placement fees involve the same customer entity, Company A, the system distinguishes the payment direction based on the fund flow relationship, and does not generate fixed accounts receivable records simply because Company A is the customer, thus meeting the needs of multi-directional settlement for the same entity in complex business transactions.

[0080] When generating provisional accounts receivable records, the system writes the project identifier, expense attribute, settlement period, payment side, collection side, amount, currency, tax rate, rule version, and calculation batch from the settlement expense results into the corresponding record. Provisional accounts receivable records can proceed to subsequent processes such as business confirmation, invoice application, and payment verification; provisional accounts payable records can proceed to subsequent processes such as supplier confirmation, payment application, and payment approval. After the record is generated, the system uniformly configures a pending confirmation status, indicating that the expense has been automatically calculated by the system based on the capital model, but still needs confirmation from business or finance personnel. In the pending confirmation status, users can view the calculation details, raise objections, supplement attachments, or submit for review; if the confirmation is successful, the record can proceed to the subsequent payment and receipt process; if the confirmation fails, the system can retain the original calculation results and generate an adjustment record or re-trigger the specified capital accounting unit.

[0081] To ensure the verifiability of expense results, the system further establishes a traceability link between provisional accounts and their generation basis. This traceability link includes at least the funding model definition identifier, funding accounting unit identifier, settlement basis data batch, settlement rule expression version, field mapping relationship, rule execution component identifier, and calculation process data. Taking customer service fees as an example, the provisional accounts receivable record not only stores the service fee amount but also links to the account consumption data batch, cash consumption field value, service fee ratio parameter, ratio rule execution component, and amount precision processing result.

[0082] In some examples, taking material production costs as an example, the provisional accounts payable record is linked to the material quantity data uploaded and approved by Company D, the acceptance quantity field, the material unit price parameter, and the unit price rule execution details. Through this linkage method, business personnel can reverse-engineer the provisional record to see which funding model rule generated the cost, which batch of basic data was used, which calculation rule was adopted, and how each step of the calculation value was formed.

[0083] When storing related data, the system can also generate an accounting evidence chain identifier for each provisional estimate record and write the original business data, audit logs, data retrieval logs, rule versions, calculation logs, and results to the log storage area. If the definition of the funding model is subsequently adjusted, such as a change in the customer rebate ratio or a reconfirmation of the material unit price, the system will not overwrite the already generated provisional estimate records. Instead, it will recalculate and generate adjustment records based on the new version of the funding model, while the original provisional estimate records will retain the corresponding historical rule versions and calculation basis. This supports continuous changes in business rules while ensuring that historical accounting results are auditable.

[0084] Through the above implementation methods, the settlement system can automatically distinguish between provisional receivables and provisional payables based on the payment and collection sides defined in the capital model. It writes customer placement fees, customer service fees, customer rebates, media recharge fees, external procurement operation service fees, and material production fees into the corresponding business modules, and establishes complete traceability for the capital model definition, settlement basic data, settlement rule expressions, and calculation process. This processing method improves the accuracy of determining the direction of settlement results, reduces the cost of manual entry and verification, and enhances the system's verification capabilities and audit traceability for expense accounting.

[0085] The following are system embodiments of this application, which can be used to execute the method embodiments of this application. For details not disclosed in the system embodiments of this application, please refer to the method embodiments of this application.

[0086] Figure 2 This is a schematic diagram of the structure of the automatic settlement fee calculation system based on the capital model definition provided in this application embodiment. Figure 2 As shown, the system includes: Module 201 is established to obtain the audited and confirmed basic settlement data under the target project, and to establish a searchable data collection unit according to the project identifier and data type. The acquisition module 202 is used to acquire the capital model definition corresponding to the target project. The capital model definition is used to represent the capital flow relationship of settlement fees between different settlement entities, and includes fee attributes, settlement entity roles, basic data reference conditions and settlement rule expressions. The matching module 203 is used to parse each settlement fee into a fund accounting unit that includes the payment side, the collection side, the data reference side and the rule calculation side according to the fund model definition, and to match the corresponding settlement basic data from the data collection unit according to the basic data reference conditions. The calculation module 204 is used to call the general settlement calculator based on the settlement rule expression when the settlement period corresponding to the fund accounting unit is reached, to calculate the fees on the matched settlement basic data, and generate the settlement fee results under the corresponding fund flow relationship; The writing module 205 is used to write the settlement fee results into the provisional accounts receivable record or provisional accounts payable record according to the attribution relationship between the payment side, the collection side and the preset settlement entity, and to associate and store the capital model definition, settlement basic data and settlement rule expression with the corresponding record.

[0087] In some embodiments, Figure 2The establishment module 201 receives business settlement data associated with the target project and configures the corresponding data access identifier according to the data source method; it performs project ownership verification and data type identification on the business settlement data, and generates a data record to be audited carrying the project identifier, data type identifier, and source identifier; after the data record to be audited meets the preset audit conditions, it converts the data record to be audited into settlement basic data and writes it into the corresponding data collection unit according to the project identifier and data type identifier; it establishes a retrieval index for the data collection unit that matches the basic data reference conditions defined in the funding model.

[0088] In some embodiments, Figure 2 The acquisition module 202 responds to the capital model configuration request for the target project by acquiring the capital flow configuration, data reference configuration, and rule calculation configuration associated with the settlement fees; it determines the settlement entity role relationship corresponding to the settlement fees based on the capital flow configuration and generates a capital flow relationship to represent the payment side and the collection side; it determines the basic data reference conditions adapted to the settlement fees based on the data reference configuration and generates the corresponding settlement rule expression based on the rule calculation configuration; it performs integrity verification and effectiveness condition verification on the capital flow relationship, basic data reference conditions, and settlement rule expression, and generates a capital model definition associated with the target project after the verification passes.

[0089] In some embodiments, Figure 2 The acquisition module 202 parses the data retrieval constraints corresponding to settlement fees in the data reference configuration, and determines the basic data reference conditions used to limit project ownership, data type, and settlement period; based on the basic data reference conditions, it determines the value fields involved in fee calculation from the preset data field mapping relationship, and generates data variables associated with settlement fees; it parses the billing logic and billing parameters configured in the rule calculation configuration, writes the data variables and billing parameters into the preset rule template, and generates settlement rule expressions; it performs consistency verification between the data variables in the settlement rule expressions and the basic data reference conditions.

[0090] In some embodiments, Figure 2 The matching module 203 reads the cost attributes and fund flow relationships corresponding to the target settlement cost in the fund model definition, and determines the payment side and collection side of the target settlement cost under the target project; based on the settlement entity roles associated with the payment side and collection side, it performs a direction consistency check on the fund flow relationship; it binds the basic data reference conditions to the data reference side of the target settlement cost, and binds the settlement rule expression to the rule calculation side of the target settlement cost; after the check passes, it generates a fund accounting unit carrying the project identifier, cost attributes, fund flow relationship, basic data reference conditions, and settlement rule expression, so that the target settlement cost can participate in subsequent cost calculation as an independent executable settlement object.

[0091] In some embodiments, Figure 2 The matching module 203 parses the basic data reference conditions carried in the fund accounting unit, determines the data retrieval range corresponding to the target project, data type, settlement period, and expense attributes; performs index retrieval in the data collection unit based on the data retrieval range, and filters candidate settlement basic data that are consistent with the target project and data type; verifies the audit status, period validity, and duplicate reference status of the candidate settlement basic data, and removes data records that do not meet the accounting conditions; establishes a reference binding relationship between the verified candidate settlement basic data and the fund accounting unit, and generates a set of settlement basic data that can be called by the rule calculation side.

[0092] In some embodiments, Figure 2 The calculation module 204 parses the settlement rule expression to determine the calculation rule type, value fields, and calculation parameters corresponding to the fund accounting unit; it matches the corresponding rule execution component from the general settlement calculator according to the calculation rule type and maps the value fields to the matched settlement basic data; it performs fee accounting based on the calculation parameters and the mapped settlement basic data to obtain the calculated value of a single fee; it summarizes and verifies the calculated value of a single fee according to the fund flow relationship, and generates a settlement fee result carrying fee attributes, payment side, collection side, and calculation basis.

[0093] In some embodiments, Figure 2 The calculation module 204 queries the registration information of rule components in the general settlement calculator according to the calculation rule type to determine the rule execution component that is compatible with the settlement rule expression; it matches and verifies the input field requirements and value fields of the rule execution component to generate a field mapping relationship; based on the field mapping relationship, it extracts the corresponding field values ​​from the matched settlement basic data and converts the field values ​​into data formats and accounting standards; it encapsulates the converted field values, calculation parameters and fund flow relationships into standardized calculation inputs and sends them to the rule execution component.

[0094] In some embodiments, Figure 2 The writing module 205 determines the payment / receipt direction identifier corresponding to the settlement fee result based on the attribution relationship between the payment side, the collection side, and the preset settlement entity. When the payment / receipt direction identifier indicates that the preset settlement entity is the collection object, a provisional accounts receivable record is generated; when the payment / receipt direction identifier indicates that the preset settlement entity is the payment object, a provisional accounts payable record is generated. The settlement fee result is written to the corresponding record, and a pending confirmation status is configured for the corresponding record. The capital model definition, settlement basic data, settlement rule expression, and calculation process data on which the settlement fee result is based are established with a traceability relationship with the corresponding record.

[0095] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0096] Figure 3 This is a schematic diagram of the electronic device 3 provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various system embodiments described above.

[0097] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or different components.

[0098] The processor 301 may be a central processing unit (CPU), or 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.

[0099] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 3. The memory 302 can also include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device.

[0100] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0101] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which may be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0102] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for automatically calculating settlement fees based on a capital model definition, characterized in that, include: Obtain the audited and confirmed basic settlement data for the target project, and establish searchable data collection units according to project identifiers and data types; Obtain the funding model definition corresponding to the target project. The funding model definition is used to characterize the fund flow relationship of settlement fees between different settlement entities, and includes fee attributes, settlement entity roles, basic data reference conditions, and settlement rule expressions. According to the definition of the funding model, each settlement fee is parsed into a funding accounting unit that includes a payment side, a collection side, a data reference side, and a rule calculation side, and the corresponding settlement basic data is matched from the data collection unit according to the basic data reference conditions. When the settlement period corresponding to the fund accounting unit is reached, the general settlement calculator is called based on the settlement rule expression to calculate the fees of the matched settlement basic data and generate the settlement fee results under the corresponding fund flow relationship. Based on the attribution relationship between the payment side, the collection side, and the preset settlement entity, the settlement fee result is written into the provisional accounts receivable record or provisional accounts payable record, and the capital model definition, the settlement basic data, and the settlement rule expression are associated and stored with the corresponding records.

2. The method according to claim 1, characterized in that, The process of acquiring the audited and confirmed basic settlement data for the target project and establishing a searchable data collection unit according to the project identifier and data type includes: Receive business settlement data associated with the target project, and configure the corresponding data access identifier according to the data source method; The business settlement data is subjected to project ownership verification and data type identification to generate a pending data record carrying a project identifier, data type identifier, and source identifier; After the data record to be audited meets the preset audit conditions, the data record to be audited is converted into settlement basic data and written into the corresponding data collection unit according to the project identifier and the data type identifier; Establish a retrieval index for the data collection unit that matches the basic data reference conditions in the definition of the funding model.

3. The method according to claim 1, characterized in that, The process of obtaining the funding model definition corresponding to the target project includes: In response to a funding model configuration request for the target project, obtain the funding flow configuration, data reference configuration, and rule calculation configuration associated with settlement fees; The settlement entity role relationship corresponding to the settlement fee is determined based on the fund flow configuration, and a fund flow relationship representing the payment side and the collection side is generated. Based on the data reference configuration, the basic data reference conditions adapted to the settlement fee are determined, and the corresponding settlement rule expression is generated based on the rule calculation configuration. The integrity and validity conditions of the fund flow relationship, basic data reference conditions and settlement rule expressions are verified. After the verification is passed, a fund model definition associated with the target project is generated.

4. The method according to claim 3, characterized in that, The step of determining the basic data reference conditions adapted to the settlement fee based on the data reference configuration, and generating the corresponding settlement rule expression based on the rule calculation configuration, includes: Parse the data retrieval constraints in the data reference configuration corresponding to the settlement fee, and determine the basic data reference conditions used to limit project ownership, data type, and settlement period; Based on the basic data reference conditions, the value fields involved in the cost calculation are determined from the preset data field mapping relationship, and data variables associated with the settlement cost are generated; The billing logic and billing parameters configured in the rule calculation configuration are parsed, and the data variables and billing parameters are written into a preset rule template to generate a settlement rule expression; The consistency of the data variables in the settlement rule expression with the basic data reference conditions is verified.

5. The method according to claim 1, characterized in that, The step of parsing each settlement fee into a fund accounting unit, comprising a payment side, a collection side, a data reference side, and a rule calculation side, according to the defined fund model, includes: Read the expense attributes and fund flow relationships corresponding to the target settlement expense in the fund model definition, and determine the payment side and collection side of the target settlement expense under the target project; Based on the settlement entity roles associated with the payment side and the collection side, the direction consistency of the fund flow relationship is verified; The basic data reference conditions are bound to the data reference side of the target settlement fee, and the settlement rule expression is bound to the rule calculation side of the target settlement fee; After verification, a fund accounting unit is generated, carrying project identifier, cost attributes, fund flow relationship, basic data reference conditions and settlement rule expression, so that the target settlement cost can participate in subsequent cost calculation as an independent and executable settlement object.

6. The method according to claim 5, characterized in that, The step of matching the corresponding settlement basic data from the data collection unit based on the basic data reference conditions includes: Analyze the basic data reference conditions carried in the fund accounting unit to determine the data retrieval range corresponding to the target project, data type, settlement period, and expense attributes; Based on the data range, perform an index retrieval in the data collection unit to filter candidate settlement basic data that are consistent with the target project and the data type; The candidate settlement basic data are checked for audit status, validity period and duplicate reference status, and data records that do not meet the accounting conditions are removed. The verified candidate settlement basic data is linked to the fund accounting unit to generate a set of settlement basic data that can be called by the rule calculation side.

7. The method according to claim 1, characterized in that, The step of calling the general settlement calculator based on the settlement rule expression to calculate fees on the matched settlement basic data and generate settlement fee results under the corresponding fund flow relationship includes: Parse the settlement rule expression to determine the calculation rule type, value fields, and calculation parameters corresponding to the fund accounting unit; According to the calculation rule type, the corresponding rule execution component is matched from the general settlement calculator, and the value field is mapped to the matched settlement basic data; Based on the calculation parameters and the mapped settlement basis data, the cost calculation is performed to obtain the calculated value of each individual cost item. The calculated values ​​of the individual expenses are summarized and verified according to the aforementioned fund flow relationship, and a settlement expense result is generated, which includes expense attributes, payment side, collection side, and calculation basis.

8. The method according to claim 7, characterized in that, The step of matching the corresponding rule execution component from the general settlement calculator according to the calculation rule type and mapping the value field to the matched settlement basic data includes: Based on the calculation rule type, query the rule component registration information in the general settlement calculator to determine the rule execution component that matches the settlement rule expression; The input field requirements of the rule execution component are matched and validated with the value field to generate a field mapping relationship; Based on the field mapping relationship, the corresponding field values ​​are extracted from the matched settlement basic data, and the field values ​​are converted in terms of data format and accounting caliber. The converted field values, calculation parameters, and fund flow relationships are encapsulated into standardized calculation inputs and sent to the rule execution component.

9. The method according to claim 1, characterized in that, The step of writing the settlement fee result into the provisional accounts receivable record or provisional accounts payable record, and associating and storing the capital model definition, the settlement basic data, and the settlement rule expression with the corresponding records, includes: Based on the attribution relationship between the payment side, the collection side, and the preset settlement entity, determine the payment / receipt direction identifier corresponding to the settlement fee result; When the payment direction identifier indicates that the preset settlement entity is the payee, a provisional accounts receivable record is generated; when the payment direction identifier indicates that the preset settlement entity is the payee, a provisional accounts payable record is generated. Write the settlement fee result into the corresponding record and configure the corresponding record with a pending confirmation status; Establish a traceability relationship between the capital model definition, settlement basis data, settlement rule expression and calculation process data on which the settlement fee results are based and the corresponding records.

10. An automatic settlement fee calculation system based on a capital model definition, characterized in that, include: Establish a module to acquire the audited and confirmed basic settlement data under the target project, and establish searchable data collection units according to project identifier and data type; The acquisition module is used to acquire the capital model definition corresponding to the target project. The capital model definition is used to characterize the capital flow relationship of settlement fees between different settlement entities, and includes fee attributes, settlement entity roles, basic data reference conditions, and settlement rule expressions. The matching module is used to parse each settlement fee into a fund accounting unit that includes a payment side, a collection side, a data reference side, and a rule calculation side according to the fund model definition, and to match the corresponding settlement basic data from the data collection unit according to the basic data reference conditions. The calculation module is used to call the general settlement calculator based on the settlement rule expression when the settlement period corresponding to the fund accounting unit is reached, to calculate the fees on the matched settlement basic data, and generate the settlement fee results under the corresponding fund flow relationship; The writing module is used to write the settlement fee result into the provisional accounts receivable record or provisional accounts payable record according to the attribution relationship between the payment side, the collection side and the preset settlement entity, and to associate and store the capital model definition, the settlement basic data and the settlement rule expression with the corresponding record.

Images