A layered architecture hospital financial calculation method and system
By introducing a layered architecture and asynchronous parallel processing, the rigid architecture and performance bottlenecks of the hospital's financial system were resolved, enabling flexible system expansion and efficient monitoring, and ensuring the real-time nature and accuracy of financial data.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ANHUI YACHUANG ELECTRONICS TECH CO LTD
- Filing Date
- 2026-04-30
- Publication Date
- 2026-07-31
AI Technical Summary
The existing hospital financial system suffers from problems such as a rigid monolithic architecture and tight coupling, performance bottlenecks caused by synchronous blocking data processing, fragile data access and transaction management, rudimentary configuration and expansion mechanisms, and poor observability, which affect system efficiency and security.
It adopts a clear layered architecture based on dependency injection, combined with an asynchronous programming model and parallel processing. It uses the new features of the .NET platform to perform system configuration and data processing through a dependency injection container and an asynchronous programming model, enabling flexible expansion and efficient monitoring.
It improves the system's flexibility and scalability, resolves performance bottlenecks, enhances the security and observability of data access, and ensures the real-time nature and accuracy of financial data.
Smart Images
Figure CN122492379A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of hospital financial data processing, and specifically to a hierarchical hospital financial calculation method and system. Background Technology
[0002] Hospital overpayment / underpayment issues have always been a major concern, as they can have serious consequences for both the hospital and patients. However, financial testing relies primarily on functional testing, which is inefficient and fails to provide a reliable way to verify the accuracy of results. Therefore, a dedicated reconciliation tool is urgently needed by testers to improve their efficiency and work quality.
[0003] The existing invention patent application document CN111461685A, entitled "Hospital Billing System," describes a system that includes an HIS server connected to a wireless switch, a payment platform server, a certificate server, and a ward wireless access point. It also includes a mobile billing cart connected to the wireless switch via the ward wireless access point. The mobile billing cart moves freely within the ward, automatically acquiring patient information, disease type, and hospitalization fees. Patients complete their hospitalization fee payment through the mobile billing cart.
[0004] The existing invention patent application document CN116188185A, entitled "Payment and Reconciliation Management Method, Apparatus, Terminal Equipment and Storage Medium", describes a method that includes: connecting to a target HIS system through a preset HIS system standard interface; configuring at least one corresponding payment channel for the target HIS system in response to user input payment channel configuration information on a cloud platform, wherein the payment channel is supported by a corresponding third-party payment platform; and performing reconciliation based on transaction data from the payment channel to obtain the corresponding reconciliation result.
[0005] However, the financial data management within the aforementioned existing hospital HIS (Hospital Information System) is a core aspect of healthcare operations, involving fund security, compliance auditing, and the quality of medical services. Shortages / overpayments can pose serious risks to hospitals and patients, escalating medical disputes, soaring management costs, and disruptions to medical processes. Therefore, the accuracy, completeness, and timeliness of financial data are crucial.
[0006] The aforementioned defects in the prior art include:
[0007] 1. Rigid monolithic architecture and tight coupling Defect Description: The entire system (interface, business logic, data access) is compiled into a single, indivisible application (monopoly). The core HIS business module is deeply coupled with the financial reconciliation module; modifications to either can trigger unpredictable problems. Adding a new payment channel (such as adding a medical insurance interface or facial recognition payment) requires recompiling and deploying the entire system.
[0008] Technical root cause: Lack of clear architectural layering and dependency injection concepts, heavy use of static classes and tight code references.
[0009] 2. Synchronous blocking data processing leads to performance bottlenecks. Defect Description: The reconciliation process is a massive, synchronous batch processing task. After finance personnel click "Start Reconciliation," the interface freezes until the reconciliation task, which can take several hours, is completed. Comparing massive amounts of data (such as millions of HIS orders and payment platform bills) is extremely inefficient in single-threaded or simple multi-threaded environments, severely consuming database resources and impacting the normal operation of other HIS services.
[0010] Technical root causes: Excessive use of foreach loops for row-by-row comparisons, or the use of a single large SQL statement for join queries. Failure to effectively utilize asynchronous programming and parallel computing libraries.
[0011] 3. Vulnerable data access and transaction management Defect description: Data access: The code uses the raw ADO.NET SqlConnection and SqlCommand, and is filled with handwritten SQL string concatenation, which makes it extremely vulnerable to SQL injection vulnerabilities and difficult to maintain.
[0012] Transaction management: Using SqlTransaction to ensure the atomicity of reconciliation leads to database connections being occupied for a long time, tables being locked, and causing a cascading drop in overall system performance.
[0013] Technical root cause: Lack of an ORM (Object-Relational Mapping) framework and unreasonable division of transaction boundaries.
[0014] 4. Inadequate configuration and expansion mechanisms Defect Description: Reconciliation rules (such as matching tolerance amounts, channel parameters, etc.) are hard-coded in C# code. Modifying any rule requires developers to modify the source code, recompile, and deploy. The system cannot adapt to rapidly changing business rules.
[0015] Technical root cause: The design concept of configuration and plug-in was not adopted.
[0016] 5. Weak observability Defect Description: The reconciliation process is like a black box. Aside from the final success or failure, finance personnel have no way of knowing the progress, which part of the data is being processed, or what anomalies have been encountered. Troubleshooting relies entirely on technicians searching "for a needle in a haystack" through messy log files or database tables.
[0017] Technical root cause: The use of Debug.WriteLine or simple text files for logging lacks a structured, centralized logging and monitoring system.
[0018] In the financial requirements testing of medical systems, software testers need to conduct precise tests on the accuracy, completeness, and timeliness of business data to discover hidden important issues. However, functional testing operations consume a lot of time and energy.
[0019] In summary, existing technologies suffer from technical problems such as rigid and tightly coupled monolithic architecture, performance bottlenecks caused by synchronous blocking data processing, fragile data access and transaction management, rudimentary configuration and expansion mechanisms, and poor observability. Summary of the Invention
[0020] The technical problem to be solved by this invention is: how to solve the technical problems of rigid and tightly coupled monolithic architecture, performance bottlenecks caused by synchronous blocking data processing, fragile data access and transaction management, rudimentary configuration and expansion mechanisms, and poor observability in the prior art.
[0021] This invention solves the above-mentioned technical problems by employing the following technical solution: A hierarchical hospital financial calculation method includes: S1. A clear layered architecture based on dependency injection is adopted to build a financial calculation system. The financial calculation system is configured to obtain and set the ip811 and ip823 parameters according to the actual needs of the hospital. S2. In the preset user interface, the applicable refund method is dynamically displayed based on the IP811 and IP823 parameters; S3. Perform exception handling. For preset scenarios, use an asynchronous programming model and parallel processing to generate and output customer explanation information. S4. Perform audit trail operations and record logs for all refund operations, including: refund method; S5. Conduct testing and verification, perform comprehensive testing on various scenarios under each combination of IP811 and IP823 parameters, and process the results to obtain financial calculations.
[0022] This invention allows for verification of each step of the test case execution, and testers can effectively grasp the real-time changes in financial data, especially in processes such as billing, refunds, discharge settlements, and cancellations. By introducing best practices in modern software development and the new features of the .NET platform, this invention solves the technical problems of rigid and tightly coupled monolithic architectures, performance bottlenecks caused by synchronous blocking data processing, fragile data access and transaction management, rudimentary configuration and extension mechanisms, and poor observability.
[0023] In a more specific technical solution, S1 uses a pre-defined layered model to drive the financial calculation system and uses the .NET built-in dependency injection container for injection operations.
[0024] In more specific technical solutions, the pre-defined layered model includes: presentation layer, application layer, domain layer, and infrastructure layer.
[0025] In more specific technical solutions, the working principle of a financial calculation system includes: Define the core reconciliation logic using the IReconciliationService interface; Implement the specific services of the IReconciliationService interface using HisReconciliationService and AlipayReconciliationService.
[0026] In a more specific technical solution, the registration operation is performed in Startup.cs using predefined commands; these predefined commands include: services.AddScoped<IReconciliationService,AlipayReconciliationService> ().
[0027] The presentation layer of this invention only depends on the abstract interface and does not concern itself with the specific implementation. When a new channel is needed, it is only necessary to implement the new service class and register it in the DI container, without modifying any existing code, thus implementing the "open / closed principle" and making the system flexible and scalable.
[0028] In a more specific technical solution, S3 includes the following preset scenarios: forced combination refunds.
[0029] In a more specific technical solution, the S3 asynchronous programming model uses pre-defined keywords to perform I / O-intensive operations asynchronously, releasing the main thread and completing UI freeze prevention operations.
[0030] In more specific technical solutions, the pre-defined keywords include: async and await; I / O intensive operations include: data access, API calls, and file read / write.
[0031] In a more specific technical solution, during the parallel processing of S3, the Task is operated in conjunction with the Task using pre-set tools to divide the data into pieces and use multi-core CPUs for parallel comparison. Pre-built tools include: Parallel.ForEach or the more advanced System.Threading.Channels.
[0032] In a more specific technical solution, a hierarchical hospital financial calculation system includes: The system configuration module is used to build a financial calculation system using a clear layered architecture based on dependency injection, to perform configuration operations on the financial calculation system, and to obtain and set the IP811 and IP823 parameters according to the actual needs of the hospital. The user interface module is used to dynamically display the applicable refund method based on the IP811 and IP823 parameters in the preset user interface. The user interface module is connected to the system configuration module. The exception handling module is used to handle exceptions. For preset situations, it adopts an asynchronous programming model and parallel processing to generate and output customer explanation information. The exception handling module is connected to the user interface module. The audit trail module is used to perform audit trail operations and record logs of all refund operations. The logs include: refund method. The audit trail module is connected to the exception handling module. The verification module is used for testing and verification. It performs comprehensive testing on various scenarios under each combination of IP811 and IP823 parameters, processes the results to obtain financial calculations, and connects to the audit trail module.
[0033] The present invention has the following advantages over the prior art: This invention allows for verification of each step of the test case execution, and testers can effectively grasp the real-time changes in financial data, especially in processes such as billing, refunds, discharge settlements, and cancellations. By introducing best practices in modern software development and the new features of the .NET platform, this invention solves the technical problems of rigid and tightly coupled monolithic architectures, performance bottlenecks caused by synchronous blocking data processing, fragile data access and transaction management, rudimentary configuration and extension mechanisms, and poor observability.
[0034] The presentation layer of this invention only depends on the abstract interface and does not concern itself with the specific implementation. When a new channel is needed, it is only necessary to implement the new service class and register it in the DI container, without modifying any existing code, thus implementing the "open / closed principle" and making the system flexible and scalable. Attached Figure Description
[0035] Figure 1This is a schematic diagram of the basic steps of a hierarchical hospital financial calculation method according to Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of data flow processing for a hierarchical hospital financial calculation method according to Embodiment 2 of the present invention. Detailed Implementation
[0036] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0037] Example 1 like Figure 1 and Figure 2 As shown, the hierarchical hospital financial calculation system provided by this invention is written in C#, incorporating best practices of modern software development and new features of the .NET platform. The hierarchical hospital financial calculation method provided by this invention includes: S1. A clear layered architecture based on dependency injection is adopted to build a financial calculation system. The financial calculation system is configured to obtain and set the ip811 and ip823 parameters according to the actual needs of the hospital. In this embodiment, to address the shortcomings of rigid monolithic architectures and tight coupling in existing technologies, the present invention adopts a clear layered architecture based on dependency injection. Specifically, the system strictly follows the layered pattern of domain-driven design (such as presentation layer, application layer, domain layer, and infrastructure layer) and uses the dependency injection container built into .NET.
[0038] Work style: The IReconciliationService interface defines the core reconciliation logic.
[0039] HisReconciliationService, AlipayReconciliationService, etc. are the specific services that implement this interface.
[0040] In Startup.cs, add a single line of code such as services.AddScoped<IReconciliationService, AlipayReconciliationService> (); Register.
[0041] S2. In the preset user interface, the applicable refund method is dynamically displayed based on the IP811 and IP823 parameters; S3. Perform exception handling. For preset scenarios, use an asynchronous programming model and parallel processing to generate and output customer explanation information. In this embodiment, to address the shortcomings of existing synchronous blocking data processing technologies, the present invention employs an asynchronous programming model and parallel processing.
[0042] In this embodiment, the asynchronous programming model extensively utilizes the `async` and `await` keywords. All I / O-intensive operations such as data access, API calls, and file read / write are asynchronous, freeing up the main thread and preventing the UI from freezing.
[0043] Parallelization of parallel processing: Use Parallel.ForEach or the more advanced System.Threading.Channels in conjunction with Task to divide massive amounts of data into chunks and leverage the capabilities of multi-core CPUs for parallel comparison.
[0044] S4. Perform audit trail operations and record logs for all refund operations, including: refund method; S5. Conduct testing and verification, perform comprehensive testing on various scenarios under each combination of IP811 and IP823 parameters, and process the results to obtain financial calculations.
[0045] Example 2 In this embodiment, the financial settlement and refund logic scheme is mainly based on the combination of two parameters, ip811 and ip823.
[0046] Parameter description: IP811 indicates refund method control, including: 1- Cash refund: The difference will be refunded only in cash.
[0047] 2. Refund to the original payment method: The difference will be refunded to the original payment channel (such as bank card or medical insurance account).
[0048] IP823 indicates the settlement mode control, where: 1-Prepayment model: Prepayments will be used to settle accounts first, and then refunds or supplements will be processed.
[0049] 2-Standard Mode: Settle directly based on actual costs, with more flexible refund and reimbursement options.
[0050] In the logic scheme adopted in this embodiment, the executed commands include, but are not limited to: ip811=1 (cash refund) & ip823=1 (prepayment mode). Discharge settlement and refund scenario: Conditions: 3 yuan deposit, 1 yuan charge, 2 yuan remaining balance for the patient.
[0051] Procedure: Refunds can only be processed in cash upon discharge, and cash must be paid when returning invoices.
[0052] Discharge settlement and payment scenarios: Payment Method 1: Pay 2 yuan via POS machine; if discharge settlement is cancelled, the original payment method will not be supported when returning the invoice, only cash can be selected (no actual impact); Payment Method 2: 1 RMB cash + 1 RMB POS payment; If you cancel the discharge settlement and return the invoice, you can only get 1 RMB back if you choose cash. The 1 RMB POS payment will not be refunded and will be credited to your prepayment. This is a forced combination refund. Payment Method 2: Pay 2 yuan in cash; if discharge settlement is cancelled, only 2 yuan can be refunded in cash when the invoice is returned; Execute: ip811=1 (cash refund) & ip823=2 (normal mode) In the discharge settlement payment scenario of this embodiment Prerequisites: 1 yuan prepayment, 3 yuan for ward billing, and 2 yuan to be paid upon discharge settlement; Supplementary payment method 1: Pay 2 yuan via POS at the time of discharge settlement; after successful discharge settlement, when continuing to refund the invoice, you can choose: refund 2 yuan to the original payment method or refund 2 yuan in cash, and the remaining 1 yuan will be recharged to the prepayment; Supplementary payment method 2: 2 yuan is required for discharge settlement, which is 1 yuan in cash + 1 yuan in POS payment; when the discharge settlement is successful and the invoice is refunded, you can choose: (1) directly refund 2 yuan in cash (2) refund 1 yuan in cash + 1 yuan in POS payment; Method 3 for supplementary payment: Pay 2 yuan in cash; if the discharge settlement is successful, the invoice can only be refunded in cash when canceling the discharge settlement.
[0053] Discharge settlement refund scenario; Conditions: 3 yuan prepayment, 1 yuan charge, 2 yuan refund upon discharge, cash only; Procedure: Cash refund is only available when returning the invoice; Refund is in cash, and cash refund is only available when returning the invoice. Execution: ip811=2 (refund via original payment method) & ip823=1 (prepayment mode) In the discharge settlement payment scenario of this embodiment, the prerequisites are: a prepayment of 1 yuan, ward accounting of 3 yuan, and a supplementary payment of 2 yuan required for discharge settlement. Payment Method 1: Pay 2 yuan via POS at the discharge settlement point; refunds to the original payment method are not supported when returning the invoice, only cash is accepted (no actual impact). Payment Method 2: 1 RMB cash + 1 RMB POS payment; If the discharge settlement is successful and then canceled, only 1 RMB cash will be refunded, and the refunded 1 RMB will be directly credited to the inpatient prepayment. Payment Method 3: Pay 2 yuan in cash; if the discharge settlement is successful and the discharge settlement is cancelled and the invoice is returned, only 2 yuan in cash can be refunded, or a combination refund will be forced. In the discharge settlement refund scenario of this embodiment, the prerequisite is: a prepayment of 3 yuan, a charge of 1 yuan, and the remaining 2 yuan of the prepayment needs to be refunded. Discharge settlement refund method 1: Cash refund of 2 yuan; when canceling discharge settlement and refunding the invoice, only cash can be collected. Discharge settlement refund method 2: 2 yuan will be refunded via POS to the original payment method. No refund or supplement will be given when canceling the discharge settlement and returning the invoice. Discharge settlement refund method 3: combined refund, that is, 1 yuan in cash + 1 yuan in POS. When canceling the discharge settlement and refunding the invoice, 1 yuan in cash will be added, and the other 1 yuan will not be refunded or added. Execute: ip811=2 (return via original route) & ip823=2 (normal mode).
[0054] In the discharge settlement payment scenario of this embodiment, the prerequisites are: a prepayment of 1 yuan, a charge of 3 yuan, and a discharge settlement payment of 2 yuan for the patient; Payment Method 1: Pay 2 yuan via POS, discharge settlement successful. When canceling discharge settlement and requesting a refund of the invoice, you can choose: (1) Cash refund of 2 yuan (2) Refund of 2 yuan via the original payment method (may be automatically combined with other refunds) Payment Method 2: 1 RMB cash + 1 RMB POS payment. If the discharge settlement is successful, the cash payment made during the discharge settlement cancellation can only be refunded as 1 RMB cash, while the POS payment can be refunded in cash or via the original payment method. Method 2 for supplementary payment: Pay 2 yuan in cash. If the discharge settlement is successful, only 2 yuan can be refunded in cash when the discharge settlement is cancelled.
[0055] In this example of discharge settlement and refund scenario, the prerequisites are: a prepayment of 3 yuan and a charge of 1 yuan; Discharge settlement refund method 1: Cash refund of 2 yuan. If the discharge settlement is successful and the invoice is refunded when the discharge settlement is cancelled, only cash refund of 2 yuan will be charged. Discharge settlement refund method 2: 2 yuan will be refunded via POS. If the discharge settlement is successful, combined payment is not supported when canceling the discharge settlement and refunding the invoice. You can choose to pay in cash or via POS. Discharge settlement refund method 2: Combined refund option: 1 yuan cash + 1 yuan POS. After successful discharge settlement, when canceling the discharge settlement and requesting a refund of the invoice, you can choose: 1 yuan cash supplement + 1 yuan other supplement or 2 yuan cash supplement. Explanation of prepayment: A deposit paid in advance by the patient upon hospitalization to offset subsequent medical expenses.
[0056] Features: refunds for overpayments and additional payments for underpayments; the balance is adjusted based on the actual expenses at the time of settlement.
[0057] Explanation of ward accounting: Medical expenses incurred by patients during their hospitalization are recorded and entered into the system in real time by the hospital department.
[0058] Related: It is independent of the prepayment, but needs to be calculated together during settlement.
[0059] In this embodiment, the settlement types include, but are not limited to: Refund settlement: If the prepayment is greater than the actual cost, the difference must be refunded to the patient.
[0060] Supplementary payment settlement: If the prepayment is less than the actual cost, the patient needs to pay the remaining amount.
[0061] In this embodiment, "refund invoice" refers to the process of voiding or canceling an issued invoice after settlement.
[0062] Related operations mean that refunds and supplements need to be processed simultaneously (such as cash difference payments, refunds to the original payment method, etc.).
[0063] "Combined refund / refund" means: a combination of cash and original payment method refunds (e.g., partial cash refund + partial original payment method refund).
[0064] Triggering conditions include, but are not limited to: system restrictions (such as failure to return via the original route) or manual selection.
[0065] In scenarios where a forced combination refund occurs, if the original refund method fails, the system will automatically switch to a cash refund for the remaining portion.
[0066] In summary, this invention allows for verification of each step of the test case execution, and testers can effectively grasp the real-time changes in financial data, especially in processes such as billing, refunds, discharge settlements, and cancellations. By introducing best practices in modern software development and the new features of the .NET platform, this invention solves the technical problems of rigid and tightly coupled monolithic architectures, performance bottlenecks caused by synchronous blocking data processing, fragile data access and transaction management, rudimentary configuration and extension mechanisms, and poor observability.
[0067] The presentation layer of this invention only depends on the abstract interface and does not concern itself with the specific implementation. When a new channel is needed, it is only necessary to implement the new service class and register it in the DI container, without modifying any existing code, thus implementing the "open / closed principle" and making the system flexible and scalable.
[0068] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A layered architecture hospital financial calculation method, characterized in that, The method includes: S1. A clear layered architecture based on dependency injection is adopted to build a financial calculation system. The financial calculation system is configured to obtain and set the ip811 and ip823 parameters according to the actual needs of the hospital. S2. In the preset user interface, the applicable refund method is dynamically displayed according to the ip811 and ip823 parameters; S3. Perform exception handling. For preset scenarios, use asynchronous programming model and parallel processing to generate and output customer explanation information. S4. Perform audit trail operations and record logs of all refund operations, wherein the logs include: refund method; S5. Conduct testing and verification. Perform comprehensive testing on various scenarios under each combination of the ip811 and ip823 parameters, and process the results to obtain the financial calculation results.
2. The layered architecture hospital financial calculation method of claim 1, wherein, In step S1, the financial calculation system is designed according to a pre-defined layered pattern, and the .NET built-in dependency injection container is used for injection operations.
3. The hierarchical hospital financial calculation method according to claim 2, characterized in that, The pre-defined layered model includes: presentation layer, application layer, domain layer, and infrastructure layer.
4. The hierarchical hospital financial calculation method according to claim 3, characterized in that, The financial calculation system operates as follows: Define the core reconciliation logic using the IReconciliationService interface; The specific services of the IReconciliationService interface are implemented using HisReconciliationService and AlipayReconciliationService.
5. The hierarchical hospital financial calculation method according to claim 3, characterized in that, In Startup.cs, registration is performed using preset commands; these preset commands include: services.AddScoped<IReconciliationService, AlipayReconciliationService> ().
6. The hierarchical hospital financial calculation method according to claim 1, characterized in that, In S3, the preset scenario includes: forced combined refund.
7. The hierarchical hospital financial calculation method according to claim 1, characterized in that, In the asynchronous programming model of S3, preset keywords are used to perform I / O-intensive operations in an asynchronous manner, releasing the main thread and completing the UI freeze prevention operation.
8. The hierarchical hospital financial calculation method according to claim 7, characterized in that, The preset keywords include the `async` and `await` keywords; the I / O-intensive operations include data access, API calls, and file read / write.
9. The hierarchical hospital financial calculation method according to claim 1, characterized in that, In the parallel processing of S3, the Task is operated in conjunction with the preset tools to divide the data into pieces and use a multi-core CPU for parallel comparison. The pre-built tools include: Parallel.ForEach or the more advanced System.Threading.Channels.
10. A hierarchical hospital financial calculation system, characterized in that, The system includes: The system configuration module is used to build a financial calculation system using a clear layered architecture based on dependency injection, to perform configuration operations on the financial calculation system, and to obtain and set the IP811 and IP823 parameters according to the actual needs of the hospital. A user interface module is used to dynamically display the applicable refund method based on the ip811 and ip823 parameters in a preset user interface. The user interface module is connected to the system configuration module. An exception handling module is used to handle exceptions. For preset situations, it adopts an asynchronous programming model and parallel processing to generate and output customer explanation information. The exception handling module is connected to the user interface module. An audit trail module is used to perform audit trail operations and record logs of all refund operations, wherein the logs include: refund method; the audit trail module is connected to the exception handling module. The verification module is used to perform testing and verification, and to conduct comprehensive testing on various scenarios under each combination of the IP811 and IP823 parameters, and process the results to obtain financial calculation results. The verification module is connected to the audit trail module.