Financial document generation method, system, and device

Abstract

The application discloses a financial voucher generation method, system and device, relates to the technical field of financial management, voucher generation and the like, and comprises the following steps: obtaining contract data, financial basic data, voucher rule data and voucher format data, wherein the contract data comprises contract basic data, contract approval data and contract payment data, and the voucher rule data is determined based on the financial basic data; in response to receiving the contract approval data and the contract payment data, performing mapping processing on the contract basic data, the contract approval data and the contract payment data based on the voucher rule data to obtain target data; performing multi-dimensional checking processing on the target data to obtain a checking result; and generating a financial voucher based on the checking result and the voucher format data.

Description

Technical Field

[0001] This application relates to the technical fields of financial management and voucher generation, and in particular to a method, system and device for generating financial vouchers. Background Technology

[0002] As enterprises accelerate their digital transformation, contract management, as a core part of enterprise operations, has an increasingly urgent need for collaboration with financial management. Contract expense items (such as price, taxes, prepayments, penalties, etc.) are key data connecting contracts and finance, and their transmission efficiency and accuracy directly determine the quality of financial vouchers generated.

[0003] The relevant technology is based on the basic account mapping function provided by enterprise ERP (Enterprise Resource Planning) systems (such as SAP (Systems, Applications & Products in Data Processing) and other financial management systems) to map contract expense items. However, it requires manually associating business data with financial accounts, which cannot solve the problems of dynamic rule adjustment and cross-system data connection, resulting in low accuracy and efficiency. Summary of the Invention

[0004] The embodiments of this application aim to at least partially solve one of the technical problems in the related art. Therefore, the purpose of the embodiments of this application is to provide a method, system, device, and medium for generating financial documents, thereby improving the accuracy and efficiency of financial document generation.

[0005] This application provides a method for generating financial vouchers, comprising: acquiring contract data, financial basic data, voucher rule data, and voucher format data, wherein the contract data includes contract basic data, contract approval data, and contract payment data, and the voucher rule data is determined based on the financial basic data; in response to receiving contract approval data and contract payment data, mapping the contract basic data, contract approval data, and contract payment data based on the voucher rule data to obtain target data; performing multi-dimensional verification processing on the target data to obtain verification results; and generating financial vouchers based on the verification results and voucher format data. For example, in response to receiving contract approval data and contract payment data, the contract basic data, contract approval data, and contract payment data are mapped based on voucher rule data to obtain target data, including: mapping the contract approval data and contract basic data based on voucher rule data to obtain first target data; mapping the contract payment data based on voucher rule data to obtain second target data; and obtaining the target data based on the first target data and the second target data.

[0006] For example, the voucher rule data includes expense item mapping data, prepayment mapping data, tax rate mapping data, and expense item cash flow mapping data; the contract basic data includes contract type data, expense item name, prepayment data, and expense item type. Based on the voucher rule data, the contract approval data and contract basic data are mapped to obtain the first target data, including: mapping the contract type data and expense item name based on the expense item mapping data to obtain debit general ledger account data; mapping the prepayment data based on the prepayment mapping data to obtain prepayment account data; mapping the expense item type based on the tax rate mapping data to obtain tax rate data and input tax account data; mapping the expense item name based on the expense item cash flow mapping data to obtain cash flow data; and obtaining the first target data based on the debit general ledger account data, prepayment account data, tax rate data, input tax account data, and cash flow data.

[0007] For example, the voucher rule data also includes payment method mapping data; mapping the contract payment data based on the voucher rule data to obtain the second target data includes: mapping the contract payment data based on the payment method mapping data to obtain credit account data; and obtaining the second target data based on the credit account data.

[0008] For example, multi-dimensional verification includes debit / credit balance verification, tax rate compliance verification, account level verification, and cash flow matching verification; contract payment data includes payment amount data; multi-dimensional verification processing is performed on the target data to obtain verification results, including at least one of the following: calculating amounts based on payment amount data, tax rate data, debit general ledger account data, prepaid accounts data, input tax account data, and credit account data to obtain debit general ledger amount data, input tax amount data, prepaid accounts amount data, and credit amount data, and performing debit / credit balance verification processing based on debit general ledger amount data, input tax amount data, prepaid accounts amount data, and credit amount data to obtain verification results; performing tax rate compliance verification processing on expense item types and tax rate data based on preset rules to obtain verification results; performing account level verification processing based on debit general ledger account data, prepaid accounts data, and input tax account data to obtain verification results; and performing cash flow matching verification processing based on expense item names and cash flow data to obtain verification results.

[0009] For example, the prepayment mapping data is determined based on the following methods: comparing the prepayment data of the contract base data with a first preset value, and when it is greater than or equal to the first preset value, determining the prepayment mapping data as the first prepayment mapping data; comparing the prepayment data of the contract base data with the first preset value, and when it is less than the first preset value, determining the prepayment mapping data as the second prepayment mapping data. For example, the financial voucher generation method further includes: verifying contract approval data and contract payment data; when the difference between the approved amount corresponding to the contract approval data and the payment amount corresponding to the contract payment data is greater than a second preset value, issuing an early warning and generating a verification notification message.

[0010] For example, generating financial vouchers based on verification results and voucher format data includes: generating financial vouchers based on verification results and voucher format data when the verification result indicates that the verification passed; and generating an error report when the verification result indicates that the verification failed, so as to modify voucher rule data based on the error report.

[0011] Another embodiment of this application provides a financial voucher generation system, comprising: an acquisition module for acquiring contract data, financial basic data, voucher rule data, and voucher format data, wherein the contract data includes contract basic data, contract approval data, and contract payment data, and the voucher rule data is determined based on the financial basic data; a mapping module for, in response to receiving contract approval data and contract payment data, performing mapping processing on the contract basic data, contract approval data, and contract payment data based on the voucher rule data to obtain target data; a verification module for performing multi-dimensional verification processing on the target data to obtain verification results; and a generation module for generating financial vouchers based on the verification results and voucher format data.

[0012] Another embodiment of this application provides an electronic device having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of any of the above embodiments.

[0013] Another embodiment of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of any of the above embodiments.

[0014] The above implementation method for generating financial vouchers includes: acquiring contract data, basic financial data, voucher rule data, and voucher format data, wherein the contract data includes basic contract data, contract approval data, and contract payment data, and the voucher rule data is determined based on the basic financial data; in response to receiving contract approval data and contract payment data, mapping the basic contract data, contract approval data, and contract payment data based on the voucher rule data to obtain target data; performing multi-dimensional verification processing on the target data to obtain verification results; and generating financial vouchers based on the verification results and voucher format data. By acquiring and integrating contract data, basic financial data, voucher rules, and format data, business data is automatically associated and mapped with financial rules. Multi-dimensional verification ensures data accuracy and compliance, and ultimately, standardized financial vouchers are automatically generated. This achieves fully automated processing from contract approval and payment to financial accounting, significantly improving the efficiency and accuracy of financial processing, reducing human error and compliance risks, and enhancing the real-time performance and consistency of financial data. Attached Figure Description

[0015] Figure 1 A flowchart of a financial document generation method provided for embodiments of this application; Figure 2 A block diagram of a financial document generation system provided for another embodiment of this application; Figure 3 A block diagram of an electronic device provided for another embodiment of this application. Detailed Implementation

[0016] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0017] As enterprises accelerate their digital transformation, contract management, as a core component of business operations, faces an increasingly urgent need for collaboration with financial management. According to relevant data, over 65% of enterprises still employ a "contract offline approval + manual financial document generation" model. Contract expense items (such as price, taxes, prepayments, and penalties) serve as crucial data connecting contracts and finance; their transmission efficiency and accuracy directly determine the quality of generated financial documents.

[0018] Currently, financial voucher generation technology mainly revolves around two major directions: "rule configuration" and "automatic triggering." On the one hand, enterprise ERP (Enterprise Resource Planning) systems (such as SAP and other financial management systems) provide basic account mapping functions, but require manual association of business data with financial accounts. On the other hand, RPA (Robotic Process Automation) technology is used to replace manual data entry, but it can only simulate manual operation processes and cannot solve the problems of dynamic rule adjustment and cross-system data connection.

[0019] The following are the core technical problems in the process of generating contract payment vouchers: (1) High dependence on manual operation and low efficiency: The current generation of contract payment vouchers requires financial personnel to manually query the financial account table based on the information of the expense items in the contract (such as service fees, equipment purchase fees, etc.), payment methods (such as bank transfer, acceptance bills, etc.), tax rates, etc., and enter the voucher data item by item. The average time for generating a single contract voucher exceeds 30 minutes, and it is impossible to process multiple contract payment requirements in batches. (2) Poor data consistency and high error rate: During the manual entry process, it is easy to encounter problems such as mismatch between expense items and financial accounts (such as misclassifying "technical service fees" as "office expenses"), deviation in tax rate calculation (such as confusing 6% and 9% VAT rates), and incorrect selection of cash flow items. According to statistics, the error rate of manually generated vouchers is about 8%-12%, and an additional 30% of manpower is required for review. (3) Low rule reusability and poor scalability: The rules for generating payment vouchers differ for different types of contracts (such as purchase contracts, service contracts, and lease contracts). The existing method requires setting up processing logic for each contract separately. When the enterprise adds new business types (such as cross-border payments) or adjusts its financial system (such as changes in account codes), it is necessary to redevelop or modify the original system extensively, resulting in high maintenance costs. (4) Disconnected process and information lag: The contract payment approval process and the financial voucher generation system are independent of each other. After approval, the payment information needs to be manually synchronized to the financial system before voucher generation can be started. This causes voucher generation to lag behind payment decisions, affecting the timeliness and accuracy of financial accounting.

[0020] The core process of the contract payment account mapping method based on the ERP system is as follows: (1) Basic data maintenance: Manually enter the basic information of the contract (contract number, Party A / Party B, amount) and the basic financial data (accounting subject, tax rate table) in the ERP system; (2) Manual account mapping: According to the type of expense item in the contract (such as "equipment purchase fee"), the financial staff manually select the corresponding general ledger account (such as "1405 inventory goods") in the "account mapping module" of the ERP system; (3) Payment information entry: After the contract is approved, the financial staff enter the payment amount, payment method (such as "bank transfer") and other information into the "accounts payable module" of the ERP; (4) Semi-automatic voucher generation: The system generates a draft voucher based on the entered payment information and the manually mapped account. The financial staff needs to manually check and click "confirm" to complete the voucher generation. This solution has been widely used in manufacturing enterprises. For example, an auto parts company uses the ERP system to process the purchase contract payment vouchers through the above process, trying to reduce the workload of manual voucher preparation.

[0021] However, the contract payment account mapping method based on the ERP system has the following disadvantages: (1) Low mapping efficiency - stemming from the inherent attribute of "manual mapping": it is necessary to manually select the corresponding account for each expense item of each contract, and a complex contract (such as an EPC (Engineering, Procurement and Construction Contract)) may contain 10+ categories of expense items (equipment fees, installation fees, design fees, supervision fees, etc.), each of which needs to be mapped separately. When the company processes 500+ contracts per month, the financial staff need to repeatedly perform the mapping operation, resulting in low mapping efficiency and the inability to batch process the expense item mapping of multiple contracts. (2) High error rate - stemming from "reliance on manual judgment" and "lack of rule verification mechanism": The mapping between expense items and accounts depends on the professional knowledge of financial personnel. If personnel are not familiar with new business expense items (such as "cross-border technology licensing fees"), they are prone to selecting the wrong account. At the same time, there is no automatic verification mechanism (such as the matching verification of tax rate and expense item, and the correlation verification of payment method and cash flow item). For example, if the "construction service" subject to the 9% tax rate is mistakenly selected as the 13% tax rate, the system cannot remind in real time, resulting in incorrect voucher data. (3) Poor rule scalability - stemming from the "static mapping relationship" design: The account mapping relationship is statically stored (such as the fixed field association of "expense item name - account code" in the database). When the enterprise's financial system is adjusted (such as the account code is upgraded from "4 digits" to "6 digits") or a new expense item type is added (such as "carbon emission reduction service fee"), all historical mapping relationships need to be manually modified, and the mapping rules for new businesses cannot be preset, resulting in the system being unable to quickly adapt to business changes. (4) Process connection gap - stemming from "independent approval and certificate generation systems": The contract approval process (such as the approval node in the OA (Office Automation) system) has no data interface with the ERP voucher generation system. The approved payment information needs to be manually exported and then entered into the ERP system. There are data omissions (such as missing "prepayment ratio") or entry delays in the intermediate links, which cause the voucher generation to lag behind the approval process and affect the efficiency of financial settlement.

[0022] In view of the above-mentioned shortcomings of the technology, the purpose of this application is as follows: (1) to realize the automatic mapping of contract expense items and financial accounts, reduce manual operation, and shorten the generation time of a single contract voucher to within 5 minutes; (2) to establish a multi-dimensional voucher rule verification mechanism to ensure the accuracy of matching of expense items, tax rates, payment methods and financial accounts, and reduce the voucher error rate to below 1%; (3) to design a dynamic rule configuration module to support rapid rule updates when new business types and financial system adjustments are added, without modifying the underlying code of the system; (4) to connect the data interface between the contract payment approval process and the financial voucher generation system, realize the automatic triggering generation of vouchers after approval, and eliminate information lag.

[0023] In view of this, the embodiments of this application provide a method for generating financial vouchers. This method is based on three core modules: "basic data configuration - voucher rule definition - automatic triggering generation" and combined with cross-system data interfaces to realize the fully automated generation of contract payment vouchers.

[0024] Figure 1 A flowchart illustrating the financial document generation method provided in this application.

[0025] like Figure 1 As shown, the financial document generation method 100 provided in this application includes, for example, steps S110-S140.

[0026] Step S110: Obtain contract data, financial basic data, voucher rule data, and voucher format data. The contract data includes contract basic data, contract approval data, and contract payment data. The voucher rule data is determined based on the financial basic data. For example, the basic contract data includes contract type data, expense item names, prepayment data, and expense item types, etc.; the voucher rule data includes expense item mapping data, prepayment mapping data, tax rate mapping data, and expense item cash flow mapping data, etc. The voucher rule data is pre-established based on the basic financial data and can be modified as needed. The basic financial data includes financial account data (such as general ledger accounts, detailed account levels, etc.), tax rate information (such as tax rate types (such as value-added tax, corporate income tax), tax rate values ​​and applicable scenarios, etc.); the voucher format data includes summary generation rules, debit and credit entry order, attachment association rules (such as association between contract data and scanned contract copies, etc.); and the contract payment data includes payment method type (such as bank transfer, commercial acceptance bill, letter of credit), payment amount data, and corresponding payment channel information, etc.

[0027] Step S120: In response to receiving contract approval data and contract payment data, the contract basic data, contract approval data and contract payment data are mapped based on the voucher rule data to obtain the target data. For example, when a user submits contract approval data in the contract approval system, and the contract approval data indicates that it has passed, the user makes payment through the contract payment system and obtains contract payment data. Based on the pre-established expense item mapping data, prepayment mapping data, tax rate mapping data, payment method mapping data, and expense item cash flow mapping data, the contract basic data, contract approval data, and contract payment data are mapped to obtain the corresponding debit general ledger account data, prepayment account data, tax rate data, input tax account data, credit account data, and cash flow data as target data.

[0028] Step S130: Perform multi-dimensional verification processing on the target data to obtain the verification results. For example, multi-dimensional verification includes debit / credit balance verification, tax rate compliance verification, account level verification, and cash flow matching verification. The amount is calculated based on the contract payment data to obtain the debit general ledger amount data, input tax amount data, prepayment amount data, and credit amount data. Debit / credit balance verification, tax rate compliance verification, account level verification, and cash flow matching verification are then performed on the debit general ledger amount data, input tax amount data, prepayment amount data, and credit amount data to obtain the verification results.

[0029] Step S140: Generate financial vouchers based on the verification results and voucher format data. For example, when the verification result passes, financial vouchers are generated based on the debit general ledger amount data, input tax amount data, prepaid account amount data, credit amount data, debit general ledger account data, prepaid account data, tax rate data, input tax account data, cash flow data, and voucher format data.

[0030] In the above embodiments, by acquiring and integrating contract data, basic financial data, voucher rules and format data, business data is automatically associated and mapped with financial rules. Multi-dimensional verification is used to ensure data accuracy and compliance, and standardized financial vouchers are automatically generated. This achieves full-process automation from contract approval and payment to financial accounting, significantly improving the efficiency and accuracy of financial processing, reducing human error and compliance risks, and enhancing the real-time and consistency of financial data.

[0031] Figure 2 A block diagram of a financial document generation system provided for another embodiment of this application.

[0032] like Figure 2As shown, this application provides a financial voucher generation system. The financial voucher generation system 200 includes: an acquisition module 210, a mapping module 220, a verification module 230, and a generation module 240. The financial voucher generation system 200 also includes: an interface layer for connecting with a contract approval system (OA), a contract payment system, and an ERP system to achieve data synchronization; and an application layer for providing user operation functions such as voucher query, rule management, and log viewing.

[0033] The acquisition module 210 (data layer, rule configuration layer - used for basic data configuration and voucher rule definition) is used to acquire contract data, financial basic data, voucher rule data and voucher format data. Among them, contract data includes contract basic data, contract approval data and contract payment data, and voucher rule data is determined based on financial basic data.

[0034] Specifically, the data layer stores basic data (contract data, financial basic data) and rule data (voucher rule data, voucher format data); the rule configuration layer provides a visual rule configuration interface, including sub-modules such as expense item account lookup table configuration (expense item mapping data) and payment method account lookup table configuration (payment method mapping data). Users define multi-dimensional voucher rules in the "rule configuration layer" and store them in the "voucher rule data"; the contract basic data synchronizes contract number data, contract type data (procurement / service / leasing), expense item list (expense item name, expense item type, expense item amount, whether prepaid), payment cycle and other information from the contract approval system (OA) through the interface layer. Contract payment data includes payment method type (e.g., bank transfer, commercial acceptance bill, letter of credit), payment amount data, and corresponding payment channel information; financial basic data includes financial account data: general ledger account code and name (e.g., "1123 Prepaid Accounts", "6001 Main Business Revenue"), detailed account level; tax rate information: tax rate type (e.g., value-added tax, corporate income tax), tax rate value (e.g., 13%, 9%, 6%), and applicable scenarios (e.g., "13% applicable to sales of goods"). Voucher format data includes voucher format templates, such as summary generation rules (e.g., "[Contract Number]_[Expense Item Name] Payment"), debit and credit entry order (debit account first, then credit account), and attachment association rules (automatically associate scanned contract documents and payment approval forms (contract approval data)).

[0035] The mapping module 220 (business logic layer) is used to respond to the received contract approval data and contract payment data, and to perform mapping processing on the contract basic data, contract approval data and contract payment data based on the voucher rule data to obtain the target data. The verification module 230 (business logic layer) is used to perform multi-dimensional verification processing on the target data and obtain the verification results. The generation module 240 (business logic layer - used to automatically trigger voucher generation) is used to generate financial vouchers based on the verification results and voucher format data.

[0036] Specifically, the business logic layer includes a rule matching engine (mapping processing), a data validation engine (multi-dimensional validation), and a voucher generation engine (voucher generation).

[0037] In the above embodiments, financial vouchers are generated using a layered architecture (a hierarchical relationship of "data layer → rule configuration layer → business logic layer → interface layer → application layer"), realizing the entire process of "basic data configuration → rule configuration → approval synchronization → voucher generation → ERP synchronization".

[0038] In one example, in response to receiving contract approval data and contract payment data, the contract basic data, contract approval data, and contract payment data are mapped based on voucher rule data to obtain target data, including: mapping the contract approval data and contract basic data based on voucher rule data to obtain first target data; mapping the contract payment data based on voucher rule data to obtain second target data; and obtaining the target data based on the first target data and the second target data.

[0039] Specifically, the first target data includes debit general ledger account data, prepaid accounts data, tax rate data, input tax data, and cash flow data. The second target data includes credit account data. By comparing contract basic data, contract approval data, contract payment data with expense item mapping data, prepaid accounts mapping data, tax rate mapping data, expense item cash flow mapping data, and payment method mapping data, the debit general ledger account data, prepaid accounts data, tax rate data, input tax data, cash flow data, and credit account data can be determined.

[0040] In one example, the voucher rule data includes expense item mapping data, prepayment mapping data, tax rate mapping data, and expense item cash flow mapping data. The contract base data includes contract type data, expense item name, prepayment data, and expense item type. Based on the voucher rule data, the contract approval data and contract base data are mapped to obtain the first target data, including: mapping the contract type data and expense item name based on the expense item mapping data to obtain debit general ledger account data; mapping the prepayment data based on the prepayment mapping data to obtain prepayment account data; mapping the expense item type based on the tax rate mapping data to obtain tax rate data and input tax account data; mapping the expense item name based on the expense item cash flow mapping data to obtain cash flow data; and obtaining the first target data based on the debit general ledger account data, prepayment account data, tax rate data, input tax account data, and cash flow data.

[0041] Specifically, for expense item mapping data, a mapping relationship of "contract type - expense item name - debit general ledger account" is established, as shown in Table 1. The system supports batch import and fuzzy matching configuration (e.g., "* service fee" is uniformly mapped to "6601 management fee"). Table 1

[0042] For tax rate mapping data, a mapping relationship of "expense item type - tax rate - input tax account" is established, as shown in Table 2: Table 2

[0043] By querying the expense item mapping data and tax rate mapping data based on the contract basic data, the corresponding debit general ledger account data, tax rate data, and input tax account data can be obtained.

[0044] For the cash flow mapping data of expense items, establish a mapping relationship of "expense item name - cash flow item". For example, "equipment purchase fee" corresponds to "cash paid for purchasing goods and receiving services", and "technical service fee" corresponds to "cash paid for other operating activities".

[0045] For example, the prepayment mapping data is determined based on the following methods: comparing the prepayment data of the contract base data with a first preset value, and when it is greater than or equal to the first preset value, determining the prepayment mapping data as the first prepayment mapping data; comparing the prepayment data of the contract base data with the first preset value, and when it is less than the first preset value, determining the prepayment mapping data as the second prepayment mapping data. Specifically, for prepayment mapping data, a "prepayment ratio threshold - prepayment account" rule is set. For example, when the prepayment ratio (prepayment data) of contract expense items (contract basic data) is ≥30% (first preset value), the corresponding account is "1123 Prepayment"; when it is <30% (second preset value), it is directly recorded in the corresponding expense / asset account.

[0046] In one example, the voucher rule data also includes payment method mapping data; the contract payment data is mapped based on the voucher rule data to obtain the second target data, including: mapping the contract payment data based on the payment method mapping data to obtain credit account data; and obtaining the second target data based on the credit account data.

[0047] Specifically, for payment method mapping data, a mapping relationship of "payment method - credit account" is established, as shown in Table 3: Table 3

[0048] By querying the payment method mapping data based on the contract payment data, the corresponding credit account data can be obtained.

[0049] For example, the voucher generation engine calls the configured rules from the "voucher rule data" to perform multi-dimensional matching of contract basic data and contract payment data: matching debit general ledger account data based on "contract type + expense item name"; matching credit accounts based on "payment method"; calculating input tax amount and matching input tax account data based on "expense item type + tax rate"; determining whether to use prepayment account data based on "prepayment ratio"; and matching cash flow items (funds flow data) based on "expense item name".

[0050] In the above embodiments, by constructing a five-dimensional rule comparison table of "expense item-subject-tax rate-payment method-cash flow", the limitations of the static mapping of "single expense item-subject" in related technologies are overcome, and intelligent matching with multiple factors is achieved. For example, the subject is automatically selected according to "contract type + expense item name + prepayment ratio", covering complex business scenarios.

[0051] In one example, multi-dimensional verification includes debit / credit balance verification, tax rate compliance verification, account hierarchy verification, and cash flow matching verification; contract payment data includes payment amount data; multi-dimensional verification processing is performed on the target data to obtain verification results, including at least one of the following: calculating amounts based on payment amount data, tax rate data, debit general ledger account data, prepaid accounts data, input tax account data, and credit account data to obtain debit general ledger amount data, input tax amount data, prepaid accounts amount data, and credit amount data, and performing debit / credit balance verification processing based on debit general ledger amount data, input tax amount data, prepaid accounts amount data, and credit amount data to obtain verification results; performing tax rate compliance verification processing on expense item types and tax rate data based on preset rules to obtain verification results; performing account hierarchy verification processing based on debit general ledger account data, prepaid accounts data, and input tax account data to obtain verification results; and performing cash flow matching verification processing based on expense item names and cash flow data to obtain verification results.

[0052] Specifically, by calculating the target data matched with the contract base data and contract payment data, the corresponding amount data for each target data can be obtained. The amount data corresponding to each target data, the target data, and the contract base data are then verified to obtain the verification results.

[0053] For example, the financial voucher generation system automatically calculates the amount of each entry in the voucher. For instance, if the technical service fee for a certain service contract is 100,000 yuan (including tax, tax rate 6%) (payment amount data, debit general ledger amount data), then: Debit "6601 Management Expenses" = 100,000 / (1 + 6%) ≈ 94,300 yuan (excluding tax amount data); Debit "222101 Input Tax" (input tax amount data) = 100,000 - 94,300 ≈ 5,700 yuan; Credit "1002 Bank Deposit" = 100,000 yuan (credit amount data). The debit general ledger amount data is equal to the sum of the amount excluding tax and the input tax amount data. The data verification engine performs a debit-credit balance check to verify whether the debit general ledger amount data is equal to the credit amount data.

[0054] The data validation engine also performs the following validations: Tax rate compliance validation: whether the matching of expense item type and tax rate data conforms to preset rules (e.g., "Construction Services" cannot select a 13% tax rate); Account level validation: whether the detailed account belongs to the corresponding debit general ledger account data (e.g., "112301 Prepaid Accounts - Equipment Payment" belongs to "1123 Prepaid Accounts"); Cash flow matching validation (funds flow matching validation): whether the matching of expense item and cash flow data (funds flow data) is unique.

[0055] In the above embodiments, the real-time verification mechanism solves the problems of poor scalability and lack of automatic verification of relevant technical rules, realizes the "ready to use" rule, adapts to the rapid changes in business and financial systems, and further improves the efficiency and accuracy of voucher generation.

[0056] In one example, the financial voucher generation method further includes: verifying contract approval data and contract payment data; when the difference between the approved amount corresponding to the contract approval data and the payment amount corresponding to the contract payment data is greater than a second preset value, issuing an early warning and generating a verification notification message.

[0057] Specifically, when a contract completes payment approval in the OA (approval status changes to "approved") system, the interface layer automatically synchronizes the approval result (approval number, approval time, and approval amount) to the financial voucher generation system. After the payment system completes the payment, it synchronizes the contract payment data, such as payment status ("payment successful" / "payment failed"), payment amount, payment time, and payment serial number, to the financial voucher generation system through the interface layer. The financial voucher generation system performs preliminary verification of the synchronized data at the "business logic layer": if the payment amount (contract payment data) deviates from the approved amount (contract approval data) by more than 5% (the second preset value), an alert is triggered and voucher generation is suspended, and the finance personnel are notified to verify.

[0058] In one example, generating a financial voucher based on the validation result and voucher format data includes: generating a financial voucher based on the validation result and voucher format data when the validation result indicates that the validation passed; and generating an error report when the validation result indicates that the validation failed, so as to modify the voucher rule data based on the error report.

[0059] Specifically, if the verification passes, proceed to the next step to generate financial vouchers; if the verification fails, generate an error report (indicating the error type and location), and allow users to modify the voucher rule data and re-trigger the matching.

[0060] The financial generation system automatically generates complete financial vouchers (including voucher number, summary, debit and credit accounts (debit general ledger account data, credit account data), amount (debit general ledger amount data, input tax amount data, prepayment amount data, credit amount data), cash flow data, and attachment links) based on the voucher template (voucher format data), and synchronizes them to the ERP system through the interface layer; at the same time, it records voucher generation logs (generation time, triggering conditions, and operator) at the application layer to support subsequent traceability.

[0061] The financial voucher generation method proposed in this application achieves the following significant technical effects: (1) Improved efficiency: The voucher generation time is reduced from 30 minutes / voucher to 5 minutes / voucher, improving efficiency by 83%; it supports batch processing of voucher generation for 100+ contracts, saving the finance department 20+ hours of manual operation time per month. (2) Improved accuracy: The multi-dimensional verification mechanism reduces the voucher error rate from 8%-12% to below 1%, reducing the voucher review workload by more than 90%; for example, after applying this solution, the number of monthly voucher errors for an electronics manufacturing company decreased from 25 to 2, significantly improving the accuracy of financial accounting. (3) Enhanced scalability: The dynamic rule configuration module supports adding new expense item types (such as "new energy subsidy fee") and adjusting financial systems (such as subject code upgrade), shortening the rule update time from the original 2 days to 1 hour, reducing maintenance costs by 75%; when a cross-border e-commerce company adds "cross-border payment" business, it only needs to configure 3 rules to achieve automatic voucher generation without modifying the system code. (4) Process collaboration optimization: The data interface of the entire process of approval-payment-voucher is opened up, and the voucher generation delay time is shortened from the original 24 hours to 1 hour, realizing the closed loop of "approval + payment success → instant voucher generation". The financial settlement cycle is shortened from 5 days per month to 3 days, meeting the enterprise's need for timely financial accounting. (5) Cost reduction: The workload of manual operation and review is reduced. After applying this solution, a medium-sized enterprise (500 people) can save RMB 150,000 in financial human resources costs per year; at the same time, it avoids tax risks caused by voucher errors (such as wrong tax payment), indirectly reducing the enterprise's compliance costs.

[0062] The financial voucher generation method and system proposed in this application are based on: (1) Multi-dimensional voucher rule system design: innovatively constructing a five-dimensional rule comparison table of "expense item-subject-tax rate-payment method-cash flow", breaking through the static mapping limitation of "single expense item-subject" in related technologies, realizing intelligent matching of multiple factors, such as automatically selecting subjects according to "contract type + expense item name + prepayment ratio", covering complex business scenarios. (2) Dynamic rule configuration and real-time verification mechanism: designing a visual rule configuration interface, supporting fuzzy matching, batch import and real-time verification (such as tax rate compliance verification, loan balance verification), solving the problems of poor scalability and lack of automatic verification of related technical rules, realizing the "ready to use" rule, adapting to the rapid changes in business and financial systems. (3) Cross-system process closed loop and automatic triggering: through the interface layer, connecting the contract approval system, payment system and ERP system, innovatively designing a dual-condition triggering mechanism of "approval passed + payment successful", realizing full-process automation of voucher generation, eliminating the gap of manual data synchronization, and solving the problem of lagging connection of existing technical processes. (4) Intelligent amount calculation and summary generation: Innovatively developed voucher amount automatic calculation engine (supports complex calculations such as tax rate splitting and prepayment ratio allocation) and intelligent summary generation rules (dynamically generate summaries based on contract number and expense item name), reducing manual calculation and input operations, and further improving the efficiency and accuracy of voucher generation.

[0063] Figure 3 A block diagram of an electronic device provided for another embodiment of this application.

[0064] Another embodiment of this application provides an electronic device having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of any of the above embodiments.

[0065] like Figure 3 As shown, for ease of understanding, embodiments of this application illustrate a specific electronic device 300.

[0066] Electronic device 300 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic device 300 may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0067] like Figure 3As shown, the electronic device 300 includes a computing unit 301, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 302 or a computer program loaded from a storage unit 308 into a random access memory (RAM) 303. The RAM 303 may also store various programs and data required for the operation of the electronic device 300. The computing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0068] Multiple components in electronic device 300 are connected to input / output (I / O) interface 305. These components include: input unit 306, such as a keyboard or mouse; output unit 307, such as various types of displays or speakers; storage unit 308, such as a disk or optical disk; and communication unit 309, such as a network interface card (NIC), modem, or wireless transceiver. Communication unit 309 allows electronic device 300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0069] The computing unit 301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 301 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 301 performs the various methods described above. For example, in some embodiments, any one or more of the various methods described above can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 308. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 300 via ROM 302 and / or communication unit 309. When the computer program is loaded into RAM 303 and executed by the computing unit 301, one or more steps of any one or more of the various methods described above can be performed. Alternatively, in other embodiments, the computing unit 301 can be configured to perform any one or more of the various methods described above by any other suitable means (e.g., by means of firmware).

[0070] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method in any of the above embodiments.

[0071] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this application, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0072] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0073] In the description of this application, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this application, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0074] In the description of this application, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc., indicating the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0075] Furthermore, the terms "first," "second," etc., used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance, or implicitly specifying the number of technical features indicated in this embodiment. Therefore, features defined with terms such as "first" and "second" in the embodiments of this application can explicitly or implicitly indicate that the embodiment includes at least one of those features. In the description of this application, the word "multiple" means at least two or more, such as two, three, four, etc., unless otherwise explicitly and specifically defined in the embodiments.

[0076] In this application, unless otherwise explicitly specified or limited in the embodiments, the terms "installation," "connection," "joining," and "fixing" appearing in the embodiments should be interpreted broadly. For example, a connection can be a fixed connection, a detachable connection, or an integral part; it can also be a mechanical connection, an electrical connection, etc. Of course, it can also be a direct connection, or an indirect connection through an intermediate medium, or it can be the internal communication between two components, or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific implementation.

[0077] In this application, unless otherwise expressly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "on top of," and "over" the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

[0078] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for generating financial vouchers, characterized in that, The method includes: Acquire contract data, financial basic data, voucher rule data, and voucher format data, wherein the contract data includes contract basic data, contract approval data, and contract payment data, and the voucher rule data is determined based on the financial basic data; In response to receiving the contract approval data and the contract payment data, the contract basic data, the contract approval data, and the contract payment data are mapped based on the voucher rule data to obtain the target data; The target data is subjected to multi-dimensional verification processing to obtain the verification results; The financial voucher is generated based on the verification result and the voucher format data.

2. The method according to claim 1, characterized in that, In response to receiving the contract approval data and the contract payment data, the system performs mapping processing on the contract basic data, the contract approval data, and the contract payment data based on the voucher rule data to obtain target data, including: Based on the voucher rule data, the contract approval data and the contract basic data are mapped to obtain the first target data; The contract payment data is mapped based on the voucher rule data to obtain the second target data; The target data is obtained based on the first target data and the second target data.

3. The method according to claim 2, characterized in that, The voucher rule data includes expense item mapping data, prepayment mapping data, tax rate mapping data, and expense item cash flow mapping data; the contract basic data includes contract type data, expense item name, prepayment data, and expense item type; the mapping process based on the voucher rule data to the contract approval data and the contract basic data to obtain the first target data includes: Based on the expense item mapping data, the contract type data and the expense item name are mapped to obtain debit general ledger account data; Based on the prepayment mapping data, the prepayment data is mapped to obtain prepayment account data; Based on the tax rate mapping data, the expense item type is mapped to obtain tax rate data and input tax account data; Based on the cost item cash flow mapping data, the cost item name is mapped to obtain cash flow data; The first target data is obtained based on the debit general ledger account data, the prepaid accounts data, the tax rate data, the input tax data, and the cash flow data.

4. The method according to claim 3, characterized in that, The voucher rule data also includes payment method mapping data; the mapping process based on the voucher rule data to obtain the contract payment data to obtain the second target data includes: Based on the payment method mapping data, the contract payment data is mapped to obtain credit account data; The second target data is obtained based on the credit account data.

5. The method according to claim 4, characterized in that, The multi-dimensional verification includes loan balance verification, tax rate compliance verification, account level verification, and cash flow matching verification; the contract payment data includes payment amount data; the multi-dimensional verification processing of the target data to obtain the verification result includes at least one of the following: Based on the payment amount data, the tax rate data, the debit general ledger account data, the prepaid accounts account data, the input tax account data, and the credit account data, the amount is calculated to obtain the debit general ledger amount data, the input tax amount data, the prepaid accounts amount data, and the credit amount data. Then, based on the debit general ledger amount data, the input tax amount data, the prepaid accounts amount data, and the credit amount data, a debit-credit balance verification process is performed to obtain the verification result. Based on preset rules, the fee item type and the tax rate data are subjected to tax rate compliance verification processing to obtain the verification result; Based on the debit general ledger account data, the prepaid accounts data, and the input tax account data, account-level verification processing is performed to obtain the verification result; Based on the expense item name and the cash flow data, a cash flow matching and verification process is performed to obtain the verification result.

6. The method according to any one of claims 3-5, characterized in that, The prepaid account mapping data is determined based on the following methods, including: The prepayment data of the contract basic data is compared with a first preset value. When it is greater than or equal to the first preset value, the prepayment mapping data is determined to be the first prepayment mapping data. The prepayment data of the contract basic data is compared with a first preset value. If it is less than the first preset value, the prepayment mapping data is determined to be the second prepayment mapping data.

7. The method according to any one of claims 1-5, characterized in that, The method further includes: The contract approval data and the contract payment data are verified. When the difference between the approved amount corresponding to the contract approval data and the payment amount corresponding to the contract payment data is greater than a second preset value, an early warning is issued and a verification notification is generated.

8. The method according to any one of claims 1-5, characterized in that, The step of generating the financial voucher based on the verification result and the voucher format data includes: When the verification result indicates that the verification has passed, the financial voucher is generated based on the verification result and the voucher format data; When the verification result indicates that the verification failed, an error report is generated so that the credential rule data can be modified based on the error report.

9. A financial voucher generation system, characterized in that, The system includes: The acquisition module is used to acquire contract data, financial basic data, voucher rule data, and voucher format data. The contract data includes contract basic data, contract approval data, and contract payment data, and the voucher rule data is determined based on the financial basic data. The mapping module is used to, in response to receiving the contract approval data and the contract payment data, perform mapping processing on the contract basic data, the contract approval data and the contract payment data based on the voucher rule data to obtain target data; The verification module is used to perform multi-dimensional verification processing on the target data and obtain the verification result. The generation module is used to generate the financial voucher based on the verification result and the voucher format data.

10. An electronic device having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1-8.

Images