R&D expense automatic collection and compliance checking method based on dynamic rule engine
Patent Information
- Application Number
- CN202610325322.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-03-17
- Publication Date
- 2026-08-07
AI Technical Summary
现有财务管理软件或项目管理工具普遍缺乏与研发活动直接关联的自动化判定与费用分摊机制,导致以下问题:不同人员对研发活动的理解存在差异,导致归集范围不一致;研发工时、代码提交、采购记录、财务凭证等数据存储于多个独立系统,难以实时聚合与关联;间接费用(如折旧、水电)的分摊缺乏可追溯的计算依据,审计风险高;通常在申报期末才进行合规检查,问题发现晚,补救成本高;如何实现一种自动化、可配置、实时性强的研发费用归集与合规性校验方法,能够基于多源业务数据,通过规则引擎自动判定研发活动、匹配与分摊费用,并实时生成符合财税要求的研发支出辅助账,同时进行动态合规预警,以降低人工干预、提升合规性与审计可追溯性
[0014]本发明的一种基于动态规则引擎的研发费用自动归集与合规性校验方法,针对现有技术中研发费用人工归集工作量大、标准不统一、合规性证据链不完整、审计风险高等问题,通过构建可配置的研发活动判定规则库与费用特征库,实现从多源业务系统中实时采集并融合数据;利用规则引擎对研发任务或工时记录进行自动分析与判定,生成有效研发活动清单及判定依据链;依据费用特征库将财务费用自动匹配或分摊至具体研发活动,并生成可追溯的分摊计算明细;在归集过程中同步执行多维度合规性实时校验,对不合规项进行分级预警与闭环处置;最终自动生成符合财税政策要求的研发支出辅助账。本发明实现了研发费用归集的全流程自动化、标准化与可审计化,显著降低了企业的合规成本与申报风险,提升了研发费用管理的效能与政策红利的获得感。
Smart Images

Figure CN122529910A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of financial data processing technology, and in particular to a method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine. Background Technology
[0002] Currently, when applying for the R&D expense super-deduction policy, SMEs mainly rely on manual methods for identifying R&D activities, collecting expenses, and checking compliance. Existing financial management software or project management tools generally lack automated judgment and expense allocation mechanisms directly related to R&D activities, leading to the following problems: different personnel have different understandings of R&D activities, resulting in inconsistent collection scope; R&D man-hours, code submissions, procurement records, financial vouchers, and other data are stored in multiple independent systems, making real-time aggregation and correlation difficult; the allocation of indirect expenses (such as depreciation and utilities) lacks traceable calculation basis, resulting in high audit risk; compliance checks are usually conducted only at the end of the application period, leading to late problem discovery and high remedial costs. The question is how to implement an automated, configurable, and real-time method for R&D expense collection and compliance verification that can automatically determine R&D activities, match and allocate expenses based on multi-source business data through a rule engine, generate R&D expenditure auxiliary ledgers that meet financial and tax requirements in real time, and provide dynamic compliance warnings to reduce manual intervention and improve compliance and audit traceability. Summary of the Invention
[0003] The purpose of this invention is to provide a method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine. This method automates, standardizes, and audits the entire process of R&D expense collection, significantly reduces the compliance costs and reporting risks for enterprises, and improves the efficiency of R&D expense management and the sense of gain from policy benefits.
[0004] To achieve the above objectives, this invention provides a method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine, comprising the following steps: Construct a configurable R&D activity determination rule base and a cost feature base; wherein, the R&D activity determination rule base is used to store rules for determining R&D activities, and the cost feature base is used to define data features of various types of costs; Raw business data is collected in real time from multiple business systems, preprocessed and standardized to generate unified business events, and a cross-system data association mapping table is established. Based on the R&D activity judgment rule base, the unified business events corresponding to R&D tasks or work hour records are automatically analyzed to determine whether they belong to valid R&D activities and generate a judgment basis chain. Based on the cost feature library, the cost items in the financial vouchers are automatically matched with the determined valid R&D activities; for indirect costs, a preset allocation model is called to perform automatic allocation calculation and generate an allocation calculation detail table. During or after the cost collection process, the effective R&D activities and collected costs are verified in real time based on pre-set compliance rules. Identified non-compliant items are given graded warnings and a closed-loop handling mechanism is formed. The R&D expense data that has passed compliance verification will be automatically used to generate an auxiliary account for R&D expenditures according to a preset account format.
[0005] This includes constructing a rule base for determining R&D activities, specifically including: Based on the analysis of fiscal and tax policy documents and enterprise-customized configurations, a rule base containing at least one rule set is constructed; wherein each judgment rule is composed of multiple condition factors combined in a logical relationship, and the condition factors include at least one of text feature factors, behavioral feature factors, output feature factors and personnel feature factors.
[0006] This involves collecting raw business data from multiple business systems in real time, preprocessing and standardizing it to generate unified business events, and establishing a cross-system data association mapping table, including: Data is collected from project management, time reporting, code repository, financial accounting, and asset and material systems through configurable data connectors; The collected data is converted into the unified business event with a unified format and published to the message middleware; The unified business events are stream-cleaned, standardized, and key information extracted. Using R&D projects or tasks as anchor points, the data association mapping table is established and maintained through direct association and intelligent inference based on multi-dimensional information.
[0007] Specifically, based on the R&D activity determination rule base, the unified business events corresponding to R&D tasks or work hour records are automatically analyzed to determine whether they belong to valid R&D activities, and a determination basis chain is generated, including: Obtain the unified business event corresponding to the work hour record or R&D task item to be judged, and obtain the associated context data by querying the data association mapping table to form an activity judgment request object; Based on the attributes of the activity determination request object, the applicable determination rule set is scheduled from the R&D activity determination rule base; For each decision rule, the condition factors are matched and the satisfaction level is calculated, and then the confidence level of a single rule is calculated. A weighted voting fusion mechanism is adopted to fuse the confidence levels of multiple rules to obtain a comprehensive judgment confidence level; The comprehensive judgment confidence level is compared with a preset threshold to determine whether it is a valid R&D activity, and a judgment basis chain containing matching details and calculation process is generated.
[0008] This includes automatically matching expense items with valid R&D activities, specifically: Based on the data features defined in the cost feature library, cost items are intelligently classified into specific cost subcategories; For items classified as direct costs, they are matched to specific valid R&D activities by examining their explicit identifiers or by implicit inference through an association tracing engine, and the matching method and confidence level are recorded. For items classified as indirect costs, the allocation base is dynamically obtained from the system according to the preset allocation model in the cost feature library, the amount allocated to each R&D project is calculated, and the allocation calculation details table is generated.
[0009] The compliance verification employs a triggering mechanism that combines event-driven and timed batch processing. The verification content includes: Personnel qualification compliance verification: Verify whether the employee positions for collecting labor costs belong to the R&D sequence, and their employment status and the proportion of R&D working hours; Verification of the authenticity and compliance of R&D activities: Review the confidence level of the R&D activities and check whether they are associated with substantial R&D outputs; Verification of the completeness and compliance of expense vouchers: Based on the voucher type requirements in the expense feature database, verify whether the expense has a complete and compliant original voucher chain; Cost allocation rationality and compliance verification: Statistical methods are used to detect anomalies in cost amounts and to verify the consistency of the indirect cost allocation model; Policy macro compliance verification: Verify whether the proportion of R&D expenses in the structure meets the policy upper limit, and filter out expense types that are prohibited from being collected.
[0010] Specifically, the tiered early warning and closed-loop management include: Based on the severity, amount of impact, and frequency of occurrence of non-compliance items, risk scores are calculated and mapped to different levels of warnings; Generate a structured compliance warning report, which includes a description of non-compliance, diagnostic information, and action recommendations; Based on the type and level of the warning, the warning information will be intelligently routed to different responsible persons and delivered in real time through multiple channels; To create a warning, a handling work order is created, the handling process of supplementary materials, explanations or data adjustments is tracked, and a verification is re-triggered after the handling to form a closed loop.
[0011] After generating the R&D expenditure subsidiary ledger, it also includes: The auxiliary ledger for R&D expenditures is automatically reconciled with the company's general financial ledger to ensure data consistency.
[0012] The method further includes: During the closed-loop process of early warning and handling, the R&D activity judgment rule base or the cost feature base is dynamically optimized and updated based on supplementary compliance evidence or confirmed exceptions.
[0013] The method further includes: Collect feedback and new compliance evidence generated during the closed-loop process of compliance verification and early warning handling; Based on the aforementioned feedback and newly added compliance evidence, the rule weights and condition factors in the R&D activity judgment rule base, or the cost classification features and allocation model parameters in the cost feature base, are dynamically optimized. By utilizing the optimized rule base and feature base, the collection and verification process is re-executed on historical or newly generated business data to verify the optimization effect and iteratively improve the accuracy and adaptability of automatic collection and compliance verification.
[0014] This invention presents an automatic R&D expense collection and compliance verification method based on a dynamic rule engine. Addressing the problems of large workload, inconsistent standards, incomplete compliance evidence chains, and high audit risks in existing technologies, this invention constructs a configurable R&D activity judgment rule base and expense feature base to achieve real-time data collection and fusion from multiple business systems. The rule engine automatically analyzes and judges R&D tasks or work hour records, generating a valid list of R&D activities and a judgment basis chain. Based on the expense feature base, financial expenses are automatically matched or allocated to specific R&D activities, generating traceable allocation calculation details. Simultaneously, multi-dimensional real-time compliance verification is performed during the collection process, with tiered warnings and closed-loop handling for non-compliant items. Finally, an auxiliary ledger of R&D expenditures that complies with financial and tax policies is automatically generated. This invention achieves full-process automation, standardization, and auditability of R&D expense collection, significantly reducing compliance costs and reporting risks for enterprises, and improving the efficiency of R&D expense management and the sense of obtaining policy benefits. Attached Figure Description
[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.
[0016] Figure 1 This is a schematic diagram illustrating the steps of a method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine, according to the first embodiment of the present invention.
[0017] Figure 2This is a simplified flowchart illustrating a method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine, provided by this invention.
[0018] Figure 3 This is a complete flowchart of a method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine provided by the present invention. Detailed Implementation
[0019] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.
[0020] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.
[0021] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."
[0022] Please see Figures 1-3 This invention provides a method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine, comprising the following steps: S1. Construct a configurable R&D activity determination rule base and a cost feature base; wherein, the R&D activity determination rule base is used to store rules for determining R&D activities, and the cost feature base is used to define data features of various costs.
[0023] Specifically, the R&D activity determination rule base provides the system with decision-making logic for determining whether a specific task belongs to "R&D activity". It is organized in a multi-layered structure of "rule set - determination rule - condition factor".
[0024] Rule set: A collection of rules tailored to different judgment dimensions or policy bases. For example: The "General Rules Collection of Fiscal and Tax Policies" contains rules extracted from the provisions of national-level R&D expense deduction policy documents (such as Caishui
[2015] No. 119).
[0025] Industry-Specific Rule Sets: For example, "Software Industry R&D Characteristics Rule Set" and "Biomedical Experiment Activity Rule Set", which can be activated according to the industry to which the enterprise belongs.
[0026] "Enterprise Custom Rule Set": Rules supplemented by enterprises based on their own R&D management practices.
[0027] Decision rules: The specific decision logic under the rule set. Each rule includes: Rule ID and Description: A unique identifier and a human-readable description of the rule (e.g., "Rule R&D-001: Judgment of Creative Activities for New Technologies, Processes and Products").
[0028] Effective conditions: The context in which the rule applies (e.g., it applies to all projects, or it applies only to "artificial intelligence" projects).
[0029] Condition factor group: The specific conditions that constitute the rule judgment logic. The factors are connected by "AND" or "OR" logic.
[0030] Conditional factors: The most basic unit of judgment, pointing to specific business data characteristics. For example: Textual feature factors: A list of keywords that must be included (or not included) in the task / requirement description (e.g., "algorithm research", "prototype design", "technical feasibility verification").
[0031] Behavioral characteristic factors: related R&D behavior indicators (e.g., code repository commits > 5 times per day, associated with experimental documents, and use of simulation tools).
[0032] Output characteristic factor: The document type of the task output (e.g., software copyright manual, experimental report, design drawings).
[0033] Personnel characteristic factors: the job attributes of the participants (e.g., job title belongs to the "R&D Engineer" or "Scientist" series).
[0034] The establishment and acquisition of rules follow the principle of "policy as the foundation and enterprises as supplements" to ensure legality and compliance at the source.
[0035] General and Industry Rules: Using natural language processing technology, publicly available financial and tax regulations, industry guidance catalogs, and guidelines for the recognition of high-tech enterprises are structurally parsed to extract normative descriptions of the definition of "R&D activities" and transform them into actionable condition factors. This process does not involve sensitive corporate information; all source documents are publicly available regulations.
[0036] Enterprise-defined rules: The system provides enterprise administrators (such as R&D directors and finance managers) with a visual rule configuration interface. Administrators do not need to write code; they can define or refine rules by using drop-down selections, form filling, and other methods, in conjunction with internal documents such as the "R&D Project Management System" and "Expense Reimbursement Standards."
[0037] The system can anonymize and analyze past audited R&D project data (with explicit authorization from the company), extracting frequently occurring task characteristics and cost patterns through machine learning models. These are then recommended to the administrator as "suggested rules," which the administrator confirms and adopts. This process must be conducted within the scope of the company's authorization, and the analysis object is anonymized feature data, without disclosing specific business content.
[0038] The expense feature library is used to define the data "genes" of various R&D expenses, that is, to describe where and how each type of expense should be identified and collected. The feature library is organized around "expense type" and a feature profile table is created for each type of expense.
[0039] Main and sub-categories of expense types: In accordance with policy requirements, main categories such as "personnel costs", "direct input costs", "depreciation and long-term deferred costs", "amortization of intangible assets", "design and testing costs", and "other related costs" are established, and further subdivided (e.g., "direct input costs" are subdivided into "material costs" and "fuel and power costs").
[0040] Cost Feature Profile Table (one table per subclass): Contains the following core fields: Feature identifier: Uniquely identifies this feature.
[0041] Data source system: Indicates the original source of the expense data (e.g., human resources system, financial accounting system, procurement management system, asset management system).
[0042] Key data fields: Identify the key field names and their meanings for this type of expense in the source system (e.g., in financial vouchers, "account code='5001.05'" corresponds to "R&D Department - Salary"; in the procurement system, "material category='laboratory consumables'").
[0043] Voucher type requirements: The types of evidence required for compliance of this type of expense (e.g., payroll, material requisition form, invoice, depreciation accrual schedule).
[0044] Allocation indicator: Indicates whether the cost is a "direct cost" (which can be directly attributed to a specific R&D project) or an "indirect cost" (which needs to be allocated among multiple projects or non-R&D departments).
[0045] Default allocation model (only required for indirect costs): predefined allocation logic (e.g., by "project R&D man-hour percentage", by "R&D personnel number percentage", by "actual usable area", etc.).
[0046] The definition and mapping of features rely on an understanding of the enterprise's compliant business processes and information system architecture. The system pre-configures standard expense feature templates based on generally accepted accounting principles and R&D expense policies. These templates do not contain any real data from the enterprise.
[0047] Enterprise Personalized Configuration and Mapping: System connectivity discovery: During the enterprise deployment and implementation phase, the system uses secure technical means (such as read-only database views and API interface documentation review) and, with explicit authorization from the enterprise and cooperation from the system administrator, identifies the relevant business systems and their data table structures that can be accessed. This process is only "structure discovery" and does not extract specific business data.
[0048] Authorized mapping configuration: Authorized implementation personnel or administrators of the enterprise can use the configuration tool provided by the system to map the "Data Source System" and "Key Data Fields" in the standard cost feature template to the actual system names and fields used by the enterprise, either through drop-down menu selection or manual mapping. For example, the "Human Resources System - Job Type Field" in the standard template can be mapped to the "HR System - 'job_title' column" actually used by the enterprise.
[0049] Compliance Confirmation: After this mapping relationship is configured, it must be reviewed and confirmed by the company's finance department to ensure that the data source pointed to by the mapping is an official and compliant source of expense records (such as official payslips or invoices that have been recorded), thereby ensuring the legality and validity of the data collected subsequently.
[0050] S2. Collect raw business data from multiple business systems in real time, preprocess and standardize it to generate unified business events, and establish a cross-system data association mapping table.
[0051] Specifically, based on the business requirements for R&D expense collection, this solution defines the multi-source data to be collected as mainly including the following five categories, covering the entire chain of R&D activities from planning and execution to resource consumption: 1. R&D process management data: Source systems: Project management systems (such as Jira, ZenTao), product management tools.
[0052] Core data: Basic information of R&D projects (project number, name, budget, start and end time), R&D tasks / user stories (task number, description, status, project, person in charge, creation and update time).
[0053] 2. R&D resource investment data: Source systems: Work hour reporting system, human resources system.
[0054] Core data: Daily / weekly work hour records submitted by employees (employee ID, name, date, number of hours worked, task / project number), and employee master data (employee ID, name, department, job title, and education information).
[0055] 3. R&D activity output and behavioral data: Source systems: code repositories (such as GitLab, GitHub), document management systems, and experimental data management platforms.
[0056] Core data: Code commit history (commit hash, author, commit time, commit comments, associated branch / tag), document creation and update history (document ID, title, type, associated project).
[0057] 4. Financial and cost data: Source systems: financial accounting system, expense reimbursement system.
[0058] Core data: Accounting vouchers (voucher number, date, account code, account name, debit / credit amount, summary information), expense reimbursement forms (reimbursement form number, reimbursing person, expense type, amount, invoice number).
[0059] 5. Asset and material consumption data: Source systems: Procurement Management System, Inventory Management System, Fixed Asset Management System.
[0060] Core data: Purchase orders (order number, material code, material description, quantity, amount, supplier), material requisition forms (requisition form number, requisitioned item / task, material code, quantity), asset cards and depreciation accrual records (asset number, asset name, monthly depreciation amount, department using the asset).
[0061] In the system, pre-configure or develop corresponding connector adapters for each type of data source that needs to be connected (such as "financial system using MySQL database", "GitLab API", "Kingdee K3 Cloud Web Service"). Enterprise administrators fill in specific connection parameters (such as database address, API URL, authentication key) through the data source configuration interface and map them to the "data source system" defined in the "Expense Feature Library" in step one. For example, the abstract name "Financial Accounting System" in the feature library can be specifically configured to point to "Kingdee EAS Database" on a server within the enterprise intranet. Set a collection strategy for each data source: real-time monitoring (monitoring database Binlog or message queue), scheduled incremental retrieval (based on the "last update timestamp" field), or scheduled full synchronization.
[0062] Each connector adapter, following a predefined unified business event data model, encapsulates the raw data read from the source system into standard-format JSON or Protocol Buffers messages. The unified business event data model includes the following common fields: unique event ID, event type (e.g., "TASK_CREATED", "TIMESHEET_SUBMITTED", "EXPENSE_POSTED"), source system, event occurrence time, data fetching time, business entity identifier (e.g., project ID, task ID, employee ID, voucher number), and event details (payload). Based on the configured strategy, each connector is scheduled to run, and the generated unified business events are pushed in real-time to designated topics in message middleware (e.g., Kafka, RocketMQ), achieving unified access and buffering of data streams.
[0063] The raw event data consumed from the message middleware needs to be cleaned and enhanced in real time in the streaming data processing pipeline.
[0064] Data verification and cleaning: Format validation: Check the integrity of the JSON structure of the event data and whether the field types are correct.
[0065] Business rule validation: Apply basic business rules, such as checking whether the "number of working hours" in the work hour record is a non-negative number, and checking whether the "end time" of a task is later than the "start time".
[0066] Null / Outlier Handling: Handle missing key fields according to preset strategies (e.g., discard, mark as to be filled, fill with default values).
[0067] Data standardization and enhancement: Time standardization: Convert all time fields to UTC timestamps according to the ISO 8601 standard.
[0068] Unified coding and naming: Based on the coding standards established by the enterprise, the codes for departments, project types, and expense types are mapped and converted to ensure that the identity of the same entity from different sources is consistent.
[0069] Key information extraction and tagging: Utilizing lightweight Natural Language Processing (NLP) models or regular expressions, predefined key entities or tags are extracted from text fields such as task descriptions, code submission comments, and credential summaries. For example, potentially related "project number" or "product version number" can be extracted from the task description to provide more clues for subsequent associations.
[0070] The preprocessed standardized events are stored in the temporary storage area of the distributed data lake / warehouse. The next step is to establish cross-system data relationships to form a complete data view centered on R&D projects / tasks. "R&D Projects" and "R&D Tasks" are defined as the core relationship anchors. They are the hubs connecting all other data entities. A "R&D Data Relationship Mapping Table" is created in the database, with core fields including: Relation Record ID, Anchor Type (Project / Task), Anchor ID, Relation Entity Type (Timesheet, Commit, Expense, PurchaseOrder...), Relation Entity ID, Relation Method (Direct Relation / Indirect Inference), Relation Confidence, and Relation Time.
[0071] For data whose R&D project / task number is already clearly recorded in the source system (such as the "Task ID" field in the work hour record, or the "Requirement Project" filled in on the purchase requisition form), the system directly extracts the identifier and creates a record in the association mapping table with the association method being "direct association" and the association confidence level being 1.0.
[0072] For data lacking direct identification, the system activates a multi-dimensional correlation inference engine: Spatiotemporal proximity correlation: For example, a travel invoice (financial event) without a project number may have its claimant and travel date matched with a work hour record (work hour event) submitted by an employee for a specific R&D project on a specific date. Based on this, the system can infer that the expense may be related to that project.
[0073] Text semantic association: For example, a document named "XX Project V1.2 Architecture Design Specification" (document event) contains project name keywords in its title, which can be fuzzily matched with project names in the R&D project list.
[0074] Process traceability: For example, the "purchase order number" of a material purchase invoice (financial event) can be traced back to the purchase order (purchase event) in the procurement system. This order may have a "requesting department" or "requirement task number", which can then be linked to the R&D department or specific task.
[0075] For indirectly inferred relationships, the system calculates a relationship confidence level (0.0 to 1.0) based on the strength of the matching rules and the completeness of the data. Relationships with a confidence level below the threshold (e.g., 0.7) will be marked as "pending review" and pushed to administrators for confirmation.
[0076] S3. Based on the R&D activity determination rule base, automatically analyze the unified business events corresponding to R&D tasks or work hour records, determine whether they belong to valid R&D activities, and generate a determination basis chain.
[0077] Specifically, continuously monitor the standardized business event stream published by the data pipeline in step two. For this step, two main types of events are consumed: TIMESHEET_SUBMITTED (Work Hours Reporting Event): Contains the number of work hours reported by an employee for a specific task on a specific date, along with the task description, etc.
[0078] TASK_UPDATED (Task Update Event): Contains detailed information about the development task synchronized from the project management tool, such as title, detailed description, status, type, creation / update time, etc.
[0079] When processing a record to be judged, the judgment engine uses the "R&D Data Association Mapping Table" established in step two to query and retrieve contextual data strongly associated with the record in real time, forming a judgment data snapshot. This snapshot may include: Detailed information about the project to which this task belongs (project name, budget, objectives).
[0080] All code commit records associated with this task (commit frequency, comment content).
[0081] The list of documents generated by this task.
[0082] Information on the job title and educational background of the employee responsible for this task.
[0083] Before entering the core decision engine, the system encapsulates the record to be decided and its associated context data into a structured "Activity Decision Request Object". This object contains all the dimensional information required for the decision and serves as a unified input interface for the rule engine.
[0084] The matching analysis process is executed in a configurable and scalable rule decision pipeline, the core of which is multi-level, interpretable rule matching and confidence fusion.
[0085] Phase 1: Rule Scheduling and Context Matching Rule scheduler: Based on the attributes in the "Activity Judgment Request Object" (such as the project type and industry to which the task belongs), it dynamically selects applicable rule sets from the "R&D Activity Judgment Rule Base" built in step one. For example, an "Artificial Intelligence Algorithm R&D" project will simultaneously call relevant rules from both the "General Rule Set of Fiscal and Tax Policies" and the "Software Industry Specific Rule Set".
[0086] Contextual Injection: Before execution, the rule engine injects contextual data from the "judgment data snapshot" into the rule's execution environment. This means that a rule can not only judge the task description itself, but also reference dynamic contextual information such as "this task has been associated with more than 3 code commits in the past week" in its conditions.
[0087] Phase Two: Multi-Condition Factor Matching and Confidence Calculation Each decision rule consists of multiple "condition factors" combined using logical relationships (AND / OR). The system independently matches each condition factor and calculates its satisfaction level. Text feature factor matching: Process: Preprocessing of text fields such as task descriptions and code submission comments, including word segmentation and stop word removal.
[0088] Strategy: A combination of semantic similarity calculation and keyword matching is used. For example, in addition to matching the keyword "algorithm optimization", the semantic similarity between the descriptive text and standard R&D phrases such as "creative experiment" and "technology verification" is calculated using a word vector model.
[0089] Output: Generate a text matching score between 0 and 1.
[0090] Behavioral characteristic factor matching: Process: Query related R&D behavior data and perform quantitative statistics.
[0091] Strategy: Execute predefined statistical queries. For example, if the condition "number of associated code commits > 5", the engine will query the number of commit records associated with the task and determine whether the condition is met.
[0092] Output: The result is a Boolean value (satisfied / not satisfied) or a normalized numerical value (e.g., number of submissions / 10, capped at 1.0).
[0093] Product characteristic factor matching: Process: Check the associated output types.
[0094] Strategy: Match with a predefined list of compliant deliverable types (e.g., design documents, test reports, prototypes).
[0095] Output: Boolean value or type matching score.
[0096] Personnel characteristic factor matching: Process: Verify the job attributes of the participants.
[0097] Strategy: Compare with the "R&D job sequence" defined in Step 1.
[0098] Output: Boolean value.
[0099] Phase 3: Rule Confidence Aggregation and Comprehensive Judgment Single-rule confidence calculation: Based on the matching results and logical relationships of each condition factor within a rule, the rule confidence for this record to be judged is calculated. For example, if the rule is "condition A AND (condition B OR condition C)", then the matching scores of the three conditions are combined and logically operated to obtain a confidence level between 0 and 1.
[0100] Multi-rule confidence fusion: Since a decision request will trigger the evaluation of multiple rules, the system uses a "weighted voting fusion engine" for the final decision.
[0101] Weighting: Each rule is assigned a different weight based on its source (e.g., policy and regulatory rules have a higher weight, while enterprise-defined rules have a medium weight) and its importance.
[0102] Fusion calculation: The confidence scores of all triggered rules are weighted and averaged according to their weights to calculate a comprehensive judgment confidence score.
[0103] Threshold determination and result generation: The overall decision confidence level is compared with a configurable decision threshold (e.g., 0.75).
[0104] If the activity is greater than or equal to the threshold, it is considered a "valid R&D activity"; otherwise, it is considered a "non-R&D activity" or a "suspected activity".
[0105] Valid working hours calculation: If a work hour is determined to be a valid R&D activity, the working hours recorded in the work hour record will be directly recorded as valid R&D working hours; for task items, the calculation can be based on the sum of their associated valid working hours records.
[0106] Phase Four: Decision Criterion Chain Generation and Output The system will generate a structured "decision criterion chain" as part of the output. This criterion chain records the following details: Which rules were matched (rule ID and description).
[0107] The specific matching results of each condition factor under each rule (e.g., the text matches the keyword "simulation" with a similarity of 0.8; the associated code was submitted 7 times, which meets the condition).
[0108] The confidence level and weight calculated for each rule.
[0109] The final fusion confidence level, decision threshold, and decision conclusion.
[0110] This "chain of judgment criteria" will be saved together with the judgment result (yes / no, effective working hours) as "digital evidence" for future compliance audits.
[0111] S4. Based on the cost feature library, automatically match the cost items in the financial vouchers with the determined valid R&D activities; for indirect costs, call the preset allocation model to perform automatic allocation calculation and generate an allocation calculation detail table.
[0112] Specifically, continuous consumption is generated by the data pipeline in step two (multi-source data collection and structured fusion) through unified business events such as EXPENSE_POSTED (expense posting event) and ASSET_DEPRECIATION (asset depreciation accrual event). These events already contain structured expense information, such as: accounting voucher events: voucher number, posting date, debit / credit account code, account name, amount, business summary, and auxiliary accounting items (such as department, project). Invoice and reimbursement form events: invoice number, invoice date, supplier, expense type, amount, claimant, and approval flow information.
[0113] For an accounting voucher containing multiple lines of details, the system breaks it down into independent atomic expense entries. Each entry is associated with a unique expense entry identifier and inherits the voucher's global information (such as voucher number and date). Using natural language processing technology, text fields such as expense summaries are parsed to extract or enhance key attributes, such as potentially implicit information like "project name," "development stage," and "equipment number," providing more clues for subsequent intelligent matching.
[0114] After obtaining the atomic cost entries, the system starts a multi-level, pipelined matching engine based on a feature library.
[0115] Phase 1: Intelligent Classification of Fee Items Feature library query: The system reads the "cost feature library" built in step one and obtains the "data feature profiles" of all predefined cost subclasses.
[0116] Multi-feature vector matching: Each expense item is transformed into a feature vector, with dimensions including: account code, summary keywords, source system, and auxiliary accounting information. Simultaneously, the "key data fields" defined for each expense subclass in the feature library are also transformed into a standard feature template vector.
[0117] Similarity Calculation and Classification: The system calculates the semantic and structural similarity between the feature vector of each expense item and the standard feature template vector. A weighted similarity algorithm is used, with the "account code" having the highest weight (because it is the most accurate). The system classifies expense items into the expense subclass with the highest similarity and records the classification confidence. For example, a voucher item with the account "R&D Expenses - Salaries" will be classified with high confidence as "Personnel Labor Expenses - Salaries".
[0118] Phase Two: Matching and Associating R&D Activities For entries already classified as direct costs (with the "Assignment flag" set to "Direct" in the feature library), the system performs an exact match with the R&D activities: Explicit association matching: Process: Directly check whether the expense item contains explicit information such as "R&D project number" or "R&D task ID" (this information may come from the auxiliary accounting items of the voucher or the parsing of the summary text).
[0119] Execution: If it exists, directly query the "List of Valid R&D Activities" output in step three to confirm that the activity exists and is valid.
[0120] Result: If confirmed to be valid, a direct matching record will be created, and the expense item will be 100% attributed to the R&D activity.
[0121] Implicit association inference matching: Scenario: When the expense item does not have a direct item identifier (e.g., an invoice that only says "purchase of experimental chips").
[0122] Process: The system starts the correlation tracing engine: Using the "data association mapping table" established in step two, other business entities related to this expense item can be found. For example, the invoice number is associated with a "purchase order," which in turn is associated with a "material requisition form," which may contain an "applicant" and a "requirement task."
[0123] By combining information from multiple dimensions such as "reimbursement applicant", "requesting department", and "purchase date", spatiotemporal cross-validation is performed with the working hours records of R&D personnel and the time range of R&D tasks.
[0124] Results: The most likely R&D activity was derived, and a derivation matching record was generated, recording the derivation path and confidence level. Matches with a confidence level below the threshold were moved to the "Pending Confirmation" queue for review by management.
[0125] Phase Three: Indirect Cost Allocation Calculation For items already classified as indirect costs (such as public utilities, general equipment depreciation, and administrative staff salaries for the entire R&D department), the system performs allocation based on a preset model: Amortization Model Invocation: Based on the "default amortization model" preset for this cost subclass in the feature library, the system invokes the specific calculation logic from the candidate model library. Commonly used models include: R&D man-hour allocation model: Allocation base = (Effective R&D man-hours of each R&D project / Total man-hours of the company); R&D personnel number ratio model: Allocation base = (Number of R&D personnel in each project / Total number of employees in the company); Actual usable area model: Allocation base = (Area occupied by each project in the R&D area / Total R&D area); Instrument and equipment time model: Allocation base = (Duration of each project using specific equipment / Total available time of equipment).
[0126] Dynamic allocation base acquisition: The allocation engine pulls the latest base data from the system in real time according to the model requirements. For example, if the "R&D man-hour percentage model" is used, the engine will request the total man-hours of each valid R&D activity in the current accounting period from the judgment result in step three.
[0127] Allocation calculation and traceability information generation: Calculation: The total indirect costs are automatically calculated and allocated to each R&D project according to the calculated allocation base ratio.
[0128] Traceability Information: The system automatically generates a detailed allocation calculation table as an unalterable audit trail. This table records in detail: the original voucher number to be allocated, the total amount, the allocation model used, the allocation base for each item (such as the specific working hours), the allocation ratio, and the allocation amount.
[0129] After all matching and allocation operations are completed, the system generates a unified record of R&D expense aggregation results. Each record includes: aggregation ID, source expense item ID, associated R&D activity / project ID, aggregation amount, expense type, matching method (direct / derived / allocated), association confidence level or allocation ratio, matching basis (e.g., direct project number) or allocation calculation details. The system maintains a real-time expense aggregation summary view based on R&D projects. This view is dynamically updated with each successful matching of expenses, providing real-time data for real-time compliance verification and auxiliary account generation.
[0130] S5. During or after the cost collection process, the effective R&D activities and collected costs are verified in real time based on pre-set compliance rules. Identified non-compliant items are given graded warnings and a closed-loop handling mechanism is formed.
[0131] Specifically, compliance verification adopts a triggering mechanism that combines event-driven and timed batch processing, embedded in key nodes of the collection process to form a dynamic monitoring network.
[0132] Triggering timing: Event-driven validation includes: Triggered after a single expense collection: When each "R&D expense collection result record" is generated in step four (expense matching and allocation module), the system immediately publishes it as a validation event. Triggered after R&D activity determination: After step three completes the determination of a batch of work hours or tasks, a check on the compliance of related activities (such as personnel qualifications) is triggered. Triggered after the addition of original vouchers: When new key vouchers (such as invoices and material requisition forms) are collected in step two, a voucher integrity check for related expenses is triggered.
[0133] Scheduled / periodic batch verification: The system sets up scheduling tasks to perform batch in-depth verification of all collected data within a specific period at fixed times on a daily, weekly, or monthly basis, focusing on checking overall and statistical compliance indicators.
[0134] Once the verification engine is triggered, it builds a complete snapshot of the compliance verification context, which pulls the following multi-dimensional data through association mapping: Core verification object: that is, the entity that triggers the verification, such as a single collection record, R&D activity record, or newly added voucher.
[0135] End-to-end data linkage: Through the "R&D data linkage mapping table" established in step two, all upstream and downstream data related to the core object can be obtained. For example, for a material cost collection record, the corresponding purchase order, warehouse receipt, material requisition form, invoice, and related R&D tasks and project information can be retrieved.
[0136] Static rules and parameters: Read the currently effective compliance rules, threshold parameters (such as cost percentage threshold), and whitelists / blacklists (such as qualified R&D positions) from the rule base and feature base in step one.
[0137] Historical and statistical benchmarks: Query historical aggregated data and industry benchmark ratios from the data warehouse for trend comparison and anomaly detection.
[0138] The system has a built-in modular, pluggable compliance rule check library that covers multi-level compliance dimensions from micro to macro. Each compliance rule is designed as an independent "checker," including rule logic, verification methods, non-compliance judgment criteria, and risk level.
[0139] 1. Verification content for personnel qualification compliance: Ensure that the identities of R&D personnel collecting labor costs comply with policy requirements.
[0140] Verification method: Rule: R&D position sequence verification. When a record associated with personnel labor costs enters the verification process, the system reads the position name from its associated "Employee Master Data" and performs semantic matching with the "R&D Position Name Keyword List" defined in the feature library. Simultaneously, it verifies whether the employee's department is within the "R&D Department" organizational structure.
[0141] Rule: Verification of R&D personnel's employment and full-time status. The system checks whether the employee is "employed" during the period in which the expense occurred, and analyzes all their work hour records during the same period to determine whether the effective work hours invested in R&D are too low (e.g., <80%), which may indicate that they are not full-time R&D personnel.
[0142] Non-compliance determination: The employee's position is obviously not in the R&D sequence (such as "sales manager"), the department is not a core R&D department, the employee has left the company during the period when the expense was incurred, or the R&D working hours are seriously insufficient and there is no reasonable explanation.
[0143] 2. Verification content for the authenticity and compliance of R&D activities: Ensure that the R&D activities to which the expenses are attributed are authentic, valid, and in accordance with the definition.
[0144] Verification method: Rule: Activity judgment result review. The verification engine will retrieve the "judgment basis chain" generated for the activity in step three, and examine whether its overall confidence level is close to the judgment threshold boundary (such as confidence level between 0.7 and 0.8), and perform a second review on boundary cases.
[0145] Rule: Evidence chain verification of activity deliverables. For activities identified as R&D activities, the system checks their associated deliverable list. If a R&D activity has no associated typical R&D deliverables such as code commits, experiment records, or design documents over a relatively long period (e.g., three months), an alert is triggered.
[0146] Non-compliance determination: The confidence level of the activity is too low and there is a lack of strong evidence to support it; the R&D activities have no substantial connection with any R&D outputs over a long period of time.
[0147] 3. Verification of the completeness and compliance of expense vouchers: Ensure that each collected expense has authentic, legal and complete original vouchers as evidence.
[0148] Verification method: Rule: Mandatory voucher type matching verification. Based on the "voucher type requirements" defined for each type of expense in the feature library, the system performs a search and matching in the associated mapping table. For example, for "direct material costs," the corresponding "purchase invoice" (proving the authenticity of the purchase) and "material requisition form" (proving that it was used for R&D) must be found simultaneously.
[0149] Rule: Verification of key voucher information. For matched vouchers, check the compliance of their key information. For example, whether the tax number on the invoice is valid, whether the invoice date is within the period in which the expense occurred, and whether the approver of the material requisition form is compliant.
[0150] Non-compliance determination: missing any required type of voucher; invalid, contradictory, or non-compliant key information on the voucher (e.g., the invoice header is not from our company).
[0151] 4. Verification content for the rationality and compliance of cost allocation: Check whether the amount and allocation method of cost allocation are reasonable and whether there are any abnormalities.
[0152] Verification method: Rule: Outlier Statistical Detection. The system maintains historical amount distribution models for each expense subclass (e.g., "Travel Expenses - Airfare"). For new aggregated records, the deviation of their amount from the historical average is calculated. The Isolation Forest algorithm or Z-Score algorithm is used to automatically identify records with abnormally high amounts.
[0153] Rule: Consistency check of allocation logic. For the allocation of indirect costs, the system checks whether the allocation model and base used for the same cost type remain consistent across different accounting periods. If a change occurs, the system requires that the reason for the change be recorded (such as adjustments to the enterprise's R&D management model); otherwise, it will be considered non-compliant.
[0154] Non-compliance criteria: A single expense amount is identified as statistically abnormal (e.g., exceeding 3 standard deviations of the historical average) without a reasonable explanation; the indirect cost allocation model is changed without justification.
[0155] 5. Verification content of macro-policy compliance: From the project or company-wide level, check whether the R&D expenses comply with the macro-policy requirements.
[0156] Verification method: Rule: Monitoring the proportion of R&D expenses. The system periodically (e.g., monthly) calculates the proportion of the total "other related expenses" of each R&D project to the "total R&D expenses" of that project, and checks whether it exceeds the policy-stipulated upper limit (e.g., 10%).
[0157] Rule: Prohibited Expense Filtering. The system maintains a list of "prohibited expense types" based on policy (e.g., business entertainment expenses, fines, late fees). Expense marked as suspicious during the expense classification stage (step four) undergoes final interception and verification here.
[0158] Non-compliance determination: The proportion of "other related expenses" in a certain R&D project exceeded the standard; the expenses were identified as the type of collection that is explicitly prohibited by policy.
[0159] The system automatically calculates a dynamic risk score based on the severity, monetary impact, frequency, and remediability of non-compliance items, and maps it to a three-level warning system. Red Alert (High Risk): This involves fundamental issues that could lead to the rejection of the entire application. Examples include: unqualified core R&D personnel, collection of explicitly prohibited expenses, and falsification of key documentation.
[0160] Yellow alert (medium risk): Involves flaws in the chain of evidence or doubts about its reasonableness, requiring supplementary explanations or materials. For example: abnormal amount of a single expense, insufficient basis for a certain apportionment, or weak chain of evidence for outputs.
[0161] Blue alert (low risk / advice): Indicates data quality or best practice recommendations. For example: overly simplistic task descriptions affecting confidence levels, or incomplete cost summary information.
[0162] Generate structured compliance alert reports that not only identify problems but also provide "problem diagnosis": Warning content: Warning ID, risk level, associated aggregation record / project, triggered compliance rule, and detailed description of non-compliance.
[0163] Diagnostic information: Automatically analyzes possible causes of non-compliance, other related suspicious data points, and historical compliance case references.
[0164] Recommendations for handling the situation: Provide specific and actionable recommendations, such as: "Please supplement the job description for employee XXX to clarify their R&D responsibilities" or "Please upload the experimental log of project Y in October 2023 as proof of output."
[0165] Based on the warning type and risk level, the system automatically pushes warnings to different responsible parties. For example, personnel qualification issues are pushed to HRBPs and R&D managers; voucher issues to finance specialists; and allocation rationality issues to the CFO. By integrating with enterprise office platforms (such as DingTalk and WeChat Work), email, and the system's message center, timely delivery of warnings is ensured. Each warning is assigned a "handling ticket" within the system. The responsible party can upload supplementary materials, submit explanations, or adjust data in the ticket. After receiving handling feedback, the system can automatically or manually re-trigger compliance verification of relevant parts and update the involved parameters. Only after successful verification can the warning ticket be closed, forming a complete "monitoring-warning-handling-verification" management loop. All warning and handling processes are logged, forming a robust digital compliance and internal control archive.
[0166] S6. Automatically generate a supplementary account for R&D expenditures based on the R&D expense data that has passed compliance verification, according to the preset account format.
[0167] Specifically, the collected and compliant R&D expense data will be automatically summarized and organized according to the subject classification format stipulated by policy; a structured R&D expenditure subsidiary ledger will be generated and automatically reconciled with the enterprise's general ledger system; real-time query, visualization, and standard format export of subsidiary ledgers will be supported, making it easy to use for additional deduction declarations.
[0168] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.
[0169] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.
Claims
1. A method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine, characterized in that, Includes the following steps: Construct a configurable R&D activity determination rule base and a cost feature base; wherein, the R&D activity determination rule base is used to store rules for determining R&D activities, and the cost feature base is used to define data features of various types of costs; Raw business data is collected in real time from multiple business systems, preprocessed and standardized to generate unified business events, and a cross-system data association mapping table is established. Based on the R&D activity judgment rule base, the unified business events corresponding to R&D tasks or work hour records are automatically analyzed to determine whether they belong to valid R&D activities and generate a judgment basis chain. Based on the cost feature library, the cost items in the financial vouchers are automatically matched with the determined valid R&D activities; for indirect costs, a preset allocation model is called to perform automatic allocation calculation and generate an allocation calculation detail table. During or after the cost collection process, the effective R&D activities and collected costs are verified in real time based on pre-set compliance rules. Identified non-compliant items are given graded warnings and a closed-loop handling mechanism is formed. The R&D expense data that has passed compliance verification will be automatically used to generate an auxiliary account for R&D expenditures according to a preset account format.
2. The method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine as described in claim 1, characterized in that, Construct a rule base for determining R&D activities, specifically including: Based on the analysis of fiscal and tax policy documents and enterprise-customized configurations, a rule base containing at least one rule set is constructed; wherein each judgment rule is composed of multiple condition factors combined in a logical relationship, and the condition factors include at least one of text feature factors, behavioral feature factors, output feature factors and personnel feature factors.
3. The method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine as described in claim 1, characterized in that, Raw business data is collected in real time from multiple business systems, preprocessed and standardized to generate unified business events, and a cross-system data association mapping table is established, including: Data is collected from project management, time reporting, code repository, financial accounting, and asset and material systems through configurable data connectors; The collected data is converted into the unified business event with a unified format and published to the message middleware; The unified business events are stream-cleaned, standardized, and key information extracted. Using R&D projects or tasks as anchor points, the data association mapping table is established and maintained through direct association and intelligent inference based on multi-dimensional information.
4. The method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine as described in claim 1 or 3, characterized in that, Based on the aforementioned R&D activity determination rule base, the unified business events corresponding to R&D tasks or work hour records are automatically analyzed to determine whether they belong to valid R&D activities, and a determination basis chain is generated, including: Obtain the unified business event corresponding to the work hour record or R&D task item to be judged, and obtain the associated context data by querying the data association mapping table to form an activity judgment request object; Based on the attributes of the activity determination request object, the applicable determination rule set is scheduled from the R&D activity determination rule base; For each decision rule, the condition factors are matched and the satisfaction level is calculated, and then the confidence level of a single rule is calculated. A weighted voting fusion mechanism is adopted to fuse the confidence levels of multiple rules to obtain a comprehensive judgment confidence level; The comprehensive judgment confidence level is compared with a preset threshold to determine whether it is a valid R&D activity, and a judgment basis chain containing matching details and calculation process is generated.
5. The method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine as described in claim 1, characterized in that, Automatically match expense items with valid R&D activities, including: Based on the data features defined in the cost feature library, cost items are intelligently classified into specific cost subcategories; For items classified as direct costs, they are matched to specific valid R&D activities by examining their explicit identifiers or by implicit inference through an association tracing engine, and the matching method and confidence level are recorded. For items classified as indirect costs, the allocation base is dynamically obtained from the system according to the preset allocation model in the cost feature library, the amount allocated to each R&D project is calculated, and the allocation calculation details table is generated.
6. The method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine as described in claim 1, characterized in that, The compliance verification adopts a triggering mechanism that combines event-driven and timed batch processing. The verification content includes: Personnel qualification compliance verification: Verify whether the employee positions for collecting labor costs belong to the R&D sequence, and their employment status and the proportion of R&D working hours; Verification of the authenticity and compliance of R&D activities: Review the confidence level of the R&D activities and check whether they are associated with substantial R&D outputs; Verification of the completeness and compliance of expense vouchers: Based on the voucher type requirements in the expense feature database, verify whether the expense has a complete and compliant original voucher chain; Cost allocation rationality and compliance verification: Statistical methods are used to detect anomalies in cost amounts and to verify the consistency of the indirect cost allocation model; Policy macro compliance verification: Verify whether the proportion of R&D expenses in the structure meets the policy upper limit, and filter out expense types that are prohibited from being collected.
7. The method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine as described in claim 1, characterized in that, The tiered early warning and closed-loop management specifically includes: Based on the severity, amount of impact, and frequency of occurrence of non-compliance items, risk scores are calculated and mapped to different levels of warnings; Generate a structured compliance warning report, which includes a description of non-compliance, diagnostic information, and action recommendations; Based on the type and level of the warning, the warning information will be intelligently routed to different responsible persons and delivered in real time through multiple channels; To create a warning, a handling work order is created, the handling process of supplementary materials, explanations or data adjustments is tracked, and a verification is re-triggered after the handling to form a closed loop.
8. The method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine as described in claim 1, characterized in that, After generating the R&D expenditure subsidiary ledger, it also includes: The auxiliary ledger for R&D expenditures is automatically reconciled with the company's general financial ledger to ensure data consistency.
9. The method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine as described in claim 1, characterized in that, The method further includes: During the closed-loop process of early warning and handling, the R&D activity judgment rule base or the cost feature base is dynamically optimized and updated based on supplementary compliance evidence or confirmed exceptions.
10. The method for automatic collection and compliance verification of R&D expenses based on a dynamic rule engine as described in claim 1, characterized in that, The method further includes: Collect feedback and new compliance evidence generated during the closed-loop process of compliance verification and early warning handling; Based on the aforementioned feedback and newly added compliance evidence, the rule weights and condition factors in the R&D activity judgment rule base, or the cost classification features and allocation model parameters in the cost feature base, are dynamically optimized. By utilizing the optimized rule base and feature base, the collection and verification process is re-executed on historical or newly generated business data to verify the optimization effect and iteratively improve the accuracy and adaptability of automatic collection and compliance verification.