Transaction code driven multi-tier accounting method

Abstract

The application discloses a transaction code driven multi-layer account bookkeeping method and particularly relates to the field of financial data processing. A cross-border payment transaction request and an account configuration table are acquired, an account level, an account type, an accounting subject, a debit and credit direction and a balance mode are matched according to a transaction code, and an account processing record is generated. A customer account, a virtual account and an internal account state are read, and an account detail set is generated. An updated balance is calculated according to the balance mode, and a deduction amount, an undeduction amount and the updated balance are recorded in the balance-off mode. When a cross-layer debit and credit difference is zero, an account master table and an account detail table are written. After receiving a correction instruction, an account balance state is recovered according to original transaction balance-off change records and balance check value continuity. The method helps to improve the consistency and correction traceability of cross-border payment multi-layer account processing.

Description

Technical Field

[0001] This invention relates to the field of financial data processing technology, and more specifically, to a transaction code-driven multi-level accounting method. Background Technology

[0002] In cross-border payment processing, a single transaction typically involves simultaneously linking the customer's visible balance account, a business-segregated virtual account, and an internal accounting account. Transaction types may also include deposits, withdrawals, currency exchanges, transaction fees, inter-channel payments, virtual card spending, digital currency collection and payment, and payments or settlements related to digital assets. With the increasing number of virtual accounts, digital currency accounts, and digital asset-related transactions, the account hierarchy, currency types, balance directions, and reversal relationships in cross-border payment accounting become more complex. Existing accounting systems can usually generate journal entries based on transaction codes or business types and update account balances using methods such as debit balance, credit balance, two-way balance, or netting balance. However, under the netting balance model, the account balance needs to be reduced in the opposite direction based on the debit / credit direction, the original debit balance, and the original credit balance. If the balance in the opposite direction is insufficient, the remaining amount is transferred to the current direction, thus forming a specific balance migration path. Existing systems often save the net balance after netting as the final result, without recording the offset amount, the unoffset amount, and the correspondence between the balances before and after the update. When a transaction fails, a channel callback fails, or a reversal is required later, if ordinary reverse posting only regenerates the opposite entry based on the reverse transaction code and the current balance, it is difficult to accurately restore the netting path when the original transaction occurred. Especially in high-concurrency scenarios, the same customer account, virtual account, or internal accounting account may have consecutive entries, exits, fee deductions, and reversals. After subsequent transactions change the account's debit and credit balance status, ordinary reverse posting can easily cause inconsistencies between the original transaction offsetting relationship and the reversal result, affecting the accounting balance between multiple layers of accounts.

[0003] How to avoid the problem that ordinary reverse accounting cannot accurately restore the original transaction netting path under the multi-level account and netting balance model of cross-border payments, and maintain cross-level accounting consistency between customer accounts, virtual accounts and internal accounting accounts in high-concurrency balance updates, is a technical problem that needs to be solved. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of existing technologies, this invention provides a transaction code-driven multi-level accounting method. By matching transaction codes with account configurations, it generates accounting details corresponding to customer accounts, virtual accounts, and internal accounts. In the netting balance mode, it records the offset amount, the unoffset amount, and the updated balance. Before writing the balance, it calculates the cross-level debit and credit difference to ensure consistency in debit and credit results among multi-level accounts. At the same time, it supports restoring the account balance state corresponding to the original transaction when reversing through balance verification values ​​and netting change records, reducing the risk that ordinary reverse accounting cannot accurately restore the original netting path.

[0005] To achieve the above objectives, this invention provides a transaction code-driven multi-level accounting method, comprising: S1. Obtain cross-border payment transaction requests and account configuration tables. Parse the transaction code, ledger number, transaction amount, currency and original transaction code from the cross-border payment transaction requests. Match the account level, account type, accounting subject, debit / credit direction and balance mode in the account configuration table according to the transaction code, and generate accounting processing records. S2. Based on the accounting records, read the corresponding customer account status, virtual account status and internal account status, obtain the balance before the update and the previous balance verification value of each account, and generate account status data. S3. Generate customer account details, virtual account details, and internal account details based on accounting records and account status data, and summarize them into an accounting details set; S4. Calculate the updated balance of the corresponding account based on the balance pattern of each account detail in the accounting detail set. For internal account details in the accounting detail set with the balance pattern of netting balance, calculate the offset amount and the unoffset amount of the opposite balance based on the debit / credit direction, transaction amount and the balance of the internal account before the update, and generate a netting change record containing the balance before the update, the offset amount, the unoffset amount and the updated balance. S5. Based on the account details identified by the account configuration table under the same ledger number and the same currency as those participating in the difference calculation, calculate the cross-level debit and credit difference between the debit and credit amounts. When the cross-level debit and credit difference is zero, generate the current balance verification value based on the netting change record and the previous balance verification value. Write the updated balance and the current balance verification value into the account master table, write the accounting details set and the netting change record into the account details table, and output the accounting processing results. S6. When a reversal instruction for a ledger number is received, read the netting change record and the current balance verification value corresponding to the original transaction. According to the writing order of the balance verification values ​​in the account details table, check whether the current balance verification value is continuous with the balance verification value corresponding to the original transaction. If they are continuous, restore the corresponding account balance status according to the netting change record and output the reversal processing result.

[0006] Furthermore, the process of generating transaction code processing records in S1 includes: obtaining a transaction code mapping table and transaction codes; matching the corresponding fee transaction codes and reversal transaction codes from the transaction code mapping table; generating a transaction code matching result containing the transaction code, fee transaction code, and reversal transaction code; and, based on the transaction code matching result, ledger number, and original transaction code, grouping the transaction code, fee transaction code, and reversal transaction code under the same ledger number to generate a transaction code processing record with the original transaction association information.

[0007] Furthermore, the process in S1 of matching account level, account type, accounting subject, lending direction, and balance mode in the account configuration table based on the transaction code includes: obtaining the transaction code processing record and the account configuration table; querying the account configuration table based on the transaction code and fee transaction code in the transaction code processing record to generate the main trading account configuration and the fee account configuration; verifying whether the account configuration under the same ledger number contains the account level, account type, accounting subject, lending direction, and balance mode based on the main trading account configuration and the fee account configuration, and generating a configuration verification result; when the configuration verification result is successful, generating an accounting processing record based on the main trading account configuration, the fee account configuration, the ledger number, the transaction amount, and the currency; and outputting a configuration exception record when the configuration verification result is unsuccessful.

[0008] Furthermore, the process of generating account status data in S2 includes: obtaining accounting records; determining the reading path for customer accounts, virtual accounts, and internal accounts based on the account type in the accounting records; reading the corresponding account status based on the customer account number, virtual account number, or accounting subject and currency to generate the account status to be verified; performing locked reading on the account status to be verified to obtain the balance before update, the previous balance verification value in the account master table, and the latest balance verification value in the account details table for each account status to generate the locked account status; comparing the previous balance verification value and the latest balance verification value in the locked account status; outputting the balance before update and the previous balance verification value as account status data when they match, and outputting an account status exception record when they do not match.

[0009] Furthermore, the process of generating a set of account details in S3 includes: acquiring account processing records and account status data; matching the account status data to customer accounts, virtual accounts, and internal accounts respectively based on the account level, account type, accounting subject, debit / credit direction, transaction amount, and currency in the account processing records, and generating customer account details, virtual account details, and internal account details; when the account processing record includes a fee transaction code, generating fee account details based on the fee account configuration and account status data corresponding to the fee transaction code, and grouping the fee account details and the main trading account details into the same account detail set under the same ledger number and the same currency; when the account processing record does not include a fee transaction code, grouping the customer account details, virtual account details, and internal account details into the same account detail set under the same ledger number and the same currency.

[0010] Furthermore, the process of grouping the set of account details in S3 includes: obtaining the set of account details; filtering customer account details, virtual account details, and internal account details from the set of account details according to the ledger number and currency to generate candidate detail groups; verifying whether the candidate detail group contains customer account details, virtual account details, and internal account details according to the account level and account type in the candidate detail group; if it contains them, the candidate detail group is determined as the detail group for cross-level loan difference calculation; if any account detail is missing, an abnormal record of the detail group is output.

[0011] Furthermore, the process of generating netting change records in S4 includes: obtaining a detail group; filtering internal account details from the detail group whose balance mode is netting balance mode and whose account type is internal account; reading the debit / credit direction, transaction amount, debit balance before update, and credit balance before update from the internal account details to generate details to be netted; based on the details to be netted, taking the pre-update balance with the opposite debit / credit direction as the offsetting balance, and calculating the offsetting amount and the unoffset amount based on the transaction amount and the offsetting balance to generate netting calculation results; determining the updated debit balance and the updated credit balance based on the netting calculation results, and writing the pre-update debit balance, pre-update credit balance, offsetting amount, unoffset amount, updated debit balance, and updated credit balance into the netting change record.

[0012] Furthermore, the process in S4 for calculating the offset amount and the unoffset amount based on the transaction amount and the offset balance includes: when the debit / credit direction of the details to be netted is debit, the offset amount is generated based on the smaller value between the transaction amount and the credit balance before the update, and the unoffset amount is generated based on the difference between the transaction amount and the offset amount; the credit balance before the update is deducted based on the offset amount, and the debit balance before the update is increased based on the unoffset amount, to generate the updated debit balance and the updated credit balance after debit netting; when the debit / credit direction of the details to be netted is credit, the offset amount is generated based on the smaller value between the transaction amount and the debit balance before the update, and the unoffset amount is generated based on the difference between the transaction amount and the offset amount, and the debit balance before the update is deducted based on the offset amount, and the credit balance before the update is increased based on the unoffset amount, to generate the updated debit balance and the updated credit balance after credit netting.

[0013] Furthermore, the process of outputting accounting results in S5 includes: obtaining the detail group and netting change records; based on the debit and credit directions and transaction amounts of the account details in the detail group that are determined by the account configuration table to participate in the difference calculation; summarizing the debit and credit amounts under the same ledger number and the same currency; calculating the difference between the debit and credit amounts; generating cross-level debit and credit differences; when the cross-level debit and credit differences are zero, generating the current balance verification value based on the netting change records, the updated balance, and the previous balance verification value; and writing the updated balance and the current balance verification value into the account master table; writing the detail group and netting change records into the account detail table; and outputting the accounting results; when the cross-level debit and credit differences are not zero, not writing into the account master table; and outputting accounting exception records based on the detail group and the cross-level debit and credit differences.

[0014] Furthermore, the process of outputting the reversal processing result in S6 includes: obtaining the ledger number in the reversal instruction; reading the netting change record corresponding to the original transaction from the account details table based on the ledger number; and reading the current balance and current balance verification value of the corresponding account from the account master table to generate the account data to be reversed; performing a continuity check between the current balance verification value and the balance verification value corresponding to the original transaction based on the balance verification values ​​arranged in the order of writing in the account details table; generating a reversal recovery instruction when the continuity check passes; and outputting a reversal exception record when the continuity check fails; and reversing the corresponding account balance status in reverse based on the reversal recovery instruction and the balance before update, the amount offset, the amount not offset, and the balance after update in the netting change record, and generating a post-reversal balance verification value based on the restored account balance, and outputting the reversal processing result.

[0015] Beneficial effects: 1. Using the transaction code as the accounting entry point, the main transaction, fee transaction, account level, lending direction and balance mode are incorporated into the same processing link, and the cross-level lending difference is verified before writing, which alleviates the accounting inconsistency caused by the fragmentation of multi-level account accounting, netting update and reversal processing in cross-border payments; 2. The transaction code mapping table associates the main transaction code, handling fee transaction code, and reversal transaction code with the same ledger number. Then, the account configuration table determines the account level, account type, and accounting subject, so that different transaction types can generate accounting records according to a unified configuration, reducing the scattered changes to the accounting logic when adding new transaction scenarios. 3. During the account status reading process, the account status is locked, and the previous balance verification value in the account master table is compared with the latest balance verification value in the account details table. Before the balance is calculated, account records that are inconsistent between the master table and the details table are identified, reducing the risk of continuing to record transactions based on incorrect balances under concurrent updates. 4. For internal accounts in the netting balance model, this invention records the loan and debit balance before the update, the offset amount, the unoffset amount, and the loan and debit balance after the update, so that the netting process is transformed from a single net amount result into a traceable balance migration record, which facilitates subsequent verification of the original transaction offsetting path and the basis for reversal and recovery. 5. After the cross-level lending difference is zero, a current balance verification value is generated. During the reversal, the account balance is restored based on the continuity of the verification value in the account details table and the original netting change record, so that the reversal process is executed along the original transaction balance path, reducing the possibility of recovery deviation caused by changes in the current balance in ordinary reverse accounting. Attached Figure Description

[0016] Figure 1 This is a flowchart of the present invention; Figure 2 This is a flowchart illustrating the transaction code matching and account configuration generation process of the present invention. Figure 3 This is a flowchart illustrating the account status reading, lock verification, and account details generation process of the present invention. Figure 4 This is a flowchart illustrating the calculation of netting discrepancy balance and the generation of netting discrepancy change records in this invention. Figure 5 This is a flowchart of the cross-level lending difference verification, balance verification chain, and reversal recovery process of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and 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.

[0018] like Figures 1 to 5 As shown, this invention provides a transaction code-driven multi-layered accounting method. The specific implementation process of this invention is explained in conjunction with the accounting scenarios of cross-border payment platforms handling deposits, fee deductions, digital asset-related payments or clearing and settlement, and subsequent reversals. In this embodiment, the cross-border payment platform is connected to a business ledger, an accounting parameter library, and an account accounting database. The business ledger is used to generate cross-border payment transaction requests, the accounting parameter library is used to store account configuration tables and transaction code mapping tables, and the account accounting database is used to store the account status, account master table, and account detail table of customer accounts, virtual accounts, and internal accounts. Figure 1 This paper illustrates the overall processing chain of this method, consisting of transaction code parsing, account configuration matching, account status reading, accounting detail generation, netting balance calculation, cross-level lending difference verification, and reversal recovery. The cross-border payment platform uses the transaction code as the entry point for accounting processing. First, it determines the relationship between the main transaction, fee transaction, and reversal transaction. Then, based on the account configuration table, it determines the account type, accounting subject, lending direction, and balance mode under different account levels. Subsequently, it reads the account status and generates customer account details, virtual account details, and internal account details. Under the netting balance mode, it records the offset amount, the unoffset amount, and the updated balance, and completes cross-level lending difference verification before writing to the account master table. When an abnormality triggers a reversal due to deposits, withdrawals, digital asset-related clearing and settlement, or channel callbacks, the platform restores the account balance status based on the continuity of the original transaction's netting change record and balance verification value.

[0019] S1. When the business ledger generates transactions related to deposits, withdrawals, exchanges, fee deductions, digital currency collection and payment, or settlement of digital assets, each transaction record is sent to the cross-border payment platform. Combined with... Figure 2 As shown, the cross-border payment platform reads the account configuration table and transaction code mapping table from the accounting parameter database. The account configuration table stores the configuration relationships between transaction codes and account levels, account types, accounting subjects, lending directions, balance modes, and identifiers for participating in difference calculations. The transaction code mapping table stores the mapping relationships between the main transaction code and the handling fee transaction code and the reversal transaction code. When a single transaction record enters the accounting processing flow, the parsing of basic transaction fields and the matching of transaction codes proceed sequentially.

[0020] The accounting process reads cross-border payment transaction requests according to field names. The transaction code field is determined as the current transaction type, the ledger number field is determined as the single transaction aggregation identifier in the business ledger, the transaction amount field is determined as the amount of the main transaction involved in the accounting, the currency field is determined as the currency to which the amount belongs, and the original transaction code field is determined as the original transaction type pointed to by the reversal transaction. The original transaction code for a positive transaction is empty, and the original transaction code for a reversal transaction is written to the transaction code of the reversed transaction.

[0021] After retrieving the transaction code field value, the accounting process uses the transaction code as the query key to perform an equal-value match in the transaction code mapping table and reads the commission transaction code and reversal transaction code from the matched records. The commission transaction code serves as the entry point for commission account configuration queries, and the reversal transaction code serves as the entry point for reversal processing. When the commission transaction code in the transaction code mapping table is empty, the commission account configuration query will not proceed; when the reversal transaction code in the transaction code mapping table is empty, the accounting process writes a transaction code mapping exception record, which stores the transaction code, ledger number, and exception reason.

[0022] Based on the obtained fee transaction code and reversal transaction code, the accounting process writes the transaction code, fee transaction code, and reversal transaction code into the same transaction code matching result. The transaction code matching result serves as the data source for subsequent transaction code processing records, ensuring that the main transaction, fee transaction, and reversal transaction have a unified transaction code source before account configuration queries.

[0023] The transaction code matching results are used to establish transaction code processing records. The accounting process uses the ledger number as the aggregation field, writing the transaction code corresponding to the main transaction, the commission transaction code, the reversal transaction code, and the original transaction code into the transaction code processing record. The original transaction code for a positive transaction is empty, and the original transaction code for a reversal transaction points to the transaction code of the reversed transaction. Taking ledger number BOOK20260001 as an example, a positive deposit transaction writes transaction code 1111, commission transaction code 1113, reversal transaction code 1115, and the empty original transaction code. Subsequent reversal requests write the same ledger number and the original transaction code 1111. The accounting process uses the ledger number and the original transaction code to locate the original main transaction and its associated commission transaction.

[0024] Based on the transaction code processing records, the accounting process queries the account configuration table using the transaction codes in the records to obtain the main trading account configuration. The account configuration table stores the accounting configurations for different account levels according to the transaction code dimension. The query results carry the account level, account type, accounting subject, debit / credit direction, and balance mode. The main trading account configuration serves as the basis for generating subsequent customer account details, virtual account details, and internal account details.

[0025] When a fee transaction code exists in the transaction code processing record, the accounting process continues to query the account configuration table using the fee transaction code to obtain the fee account configuration. The fee account configuration determines the account level, account type, accounting subject, debit / credit direction, and balance mode of the fee deduction account and the fee income account; when the fee transaction code is empty, the fee account configuration record is empty, and the fee account configuration is defaulted in the accounting record.

[0026] The main trading account configuration and fee account configuration enter the field integrity verification process. The accounting process reads the account level, account type, accounting subject, debit / credit direction, and balance mode from each account configuration entry, using the same ledger number as the scope. In the configuration records of the customer account level and virtual account level, the accounting subject field records the subject identifier corresponding to the customer balance or virtual balance, and the accounting subject field of the internal account level records the internal subject code. When the fee transaction code is empty, the accounting process does not perform mandatory field verification on the fee account configuration; it only performs field integrity verification on the customer account level, virtual account level, and internal account level configurations in the main trading account configuration. When account type, lending direction, or balance mode is missing, the configuration verification result is written as "failed"; when the internal account layer configuration is missing an accounting subject, the configuration verification result is written as "failed"; when the main trading account configuration is missing any level of customer account layer, virtual account layer, or internal account layer, the configuration verification result is written as "failed"; when the commission transaction code has a valid value and the commission account configuration is missing account type, accounting subject, lending direction, or balance mode, the configuration verification result is written as "failed"; when all configurations meet the field completeness requirements, the configuration verification result is written as "passed".

[0027] Records that pass configuration verification are assembled into accounting records. The accounting process writes the main trading account configuration, fee account configuration, ledger number, transaction amount, and currency into the accounting record. The accounting record stores the data required for subsequent account status retrieval and accounting detail generation; each account configuration carries the corresponding amount and currency. The amount corresponding to the main trading account configuration is the transaction amount, and the amount corresponding to the fee account configuration is the fee amount from the business ledger. The accounting record also carries the customer account number and virtual account number bound to the ledger number in the business ledger. The customer account number is used for subsequent retrieval of customer account status, and the virtual account number is used for subsequent retrieval of virtual account status. When the configuration verification fails, the accounting process outputs a configuration exception record, which includes the ledger number, transaction code, exception account level, missing fields, and exception reason.

[0028] S2. The accounting processing record enters the account status reading stage. The account type is used to determine the reading path for accessing customer accounts, virtual accounts, or internal accounts, and the currency is used to limit the currency balance records under the same account. Combined with... Figure 3 As shown, the accounting process assigns reading paths based on account type and reads the corresponding account status to provide a balance source for the subsequent generation of accounting details.

[0029] For customer accounts, the accounting process accesses the customer account master table based on the customer account number and currency in the accounting record to read the corresponding customer account status. The customer account status includes at least the customer account number, currency, balance mode, previous balance, and the previous balance verification value from the account master table. The customer account number originates from the customer identity or payment / receiving account field corresponding to the cross-border payment transaction request, and the currency originates from the accounting record. The read result is then entered into the pending account status verification process and undergoes lock verification along with the virtual account status and internal account status.

[0030] For virtual accounts, the accounting process accesses the virtual account master table based on the virtual account number and currency in the accounting records to read the corresponding virtual account status. The virtual account number originates from the segregated account identifier assigned to customers or business scenarios in the business ledger, used to distinguish the business balance of the same customer in different business, channel, or digital asset-related clearing and settlement scenarios. The read virtual account status is written to the account status to be verified, enabling subsequent accounting details to be generated according to business segregation criteria.

[0031] For internal accounts, the accounting process determines the internal account to be retrieved based on the accounting subject and currency. The accounting subjects for internal accounts are derived from the account configuration table, representing internal accounting subjects such as inter-channel payments, handling fee income, and clearing and settlement transition funds. The account accounting database stores an internal account index table, which records at least the correspondence between accounting subjects, currencies, and internal account numbers. The accounting process uses the accounting subject and currency as joint query conditions, performs an equal-value match in the internal account index table, retrieves the corresponding internal account number, and uses this to retrieve the internal account status from the main internal account table. The retrieved internal account status is written to the account status to be verified, used for subsequent internal account details and netting balance calculations.

[0032] After the three types of account statuses are read, the accounting process aggregates the customer account status, virtual account status, and internal account status into a pending verification account status, categorized by the same ledger number and currency. The pending verification account status retains the account type, account number, currency, balance mode, previous balance, and previous balance verification value. When the balance mode is a debit balance mode, the previous balance is taken from the debit balance field; when the balance mode is a credit balance mode, the previous balance is taken from the credit balance field; when the balance mode is a two-way balance mode or a netting balance mode, the previous balance is taken from both the previous debit balance and the previous credit balance. These values ​​serve as the basis for subsequent calculations under different balance modes.

[0033] For the account status to be verified, the accounting process performs a locked read. The locked read uses the account number and currency as the locking objects, applying a row-level exclusive lock to the corresponding account record in the customer account master table, virtual account master table, and internal account master table; other balance update requests under the same account number and currency are not written to the account master table before the current transaction is completed. Under the locked state, the accounting process rereads the pre-update balance in the locked account record and the previous balance verification value in the account master table, ensuring that the locked balance field serves as the basis for subsequent calculations.

[0034] After obtaining the previous balance verification value from the account master table, the accounting process queries the account details table for the most recently written account details under the same account number and currency, and reads the latest balance verification value from the account details table. The latest account details are obtained in reverse order of the write time or the detail serial number; if the corresponding account details do not exist in the account details table, the latest balance verification value is taken from the initial balance verification value in the account opening record. The initial balance verification value is generated by the account number, currency, initial debit balance, initial credit balance, and account opening record identifier, and is saved with the account opening record.

[0035] The locked account status consists of the balance before the update, the previous balance verification value in the account master table, and the latest balance verification value in the account details table. Taking the aforementioned USD deposit business as an example, the customer account number and currency USD determine the customer account status, the virtual account number and currency USD determine the virtual account status, and the channel receivables accounting item and USD determine the internal account status; all three types of account records have been locked and read, and the accounting process writes the balance field of each account and the two types of balance verification values ​​into the locked account status.

[0036] Locked account status serves as a consistency verification object. The accounting process compares the previous balance checksum in the account master table with the latest balance checksum in the account details table for each account. When both are completely consistent, it indicates that the account master table balance and the latest balance record in the account details table are consistent, and the accounting process outputs the previous balance and the previous balance checksum as account status data. The account status data is then used in the customer account details, virtual account details, and internal account details generation processes.

[0037] When the previous balance verification value and the latest balance verification value are inconsistent, the accounting process outputs an account status anomaly record. This record includes the ledger number, account type, account number, currency, the previous balance verification value in the account master table, the latest balance verification value in the account details table, and the reason for the anomaly. This is used to locate the source of the inconsistency between the account master table and the account details table. Accounts with an account status anomaly record will not proceed to the current balance update process.

[0038] S3. After the account status data is output, the accounting process uses the accounting records as the basis for generating details and the account status data as the source of the balance. The accounting records store the account level, account type, accounting subject, debit / credit direction, transaction amount, and currency. The account status data stores the account number, the balance before the update, and the previous balance verification value for each account. Figure 3 As shown, the accounting process first locates the account status data according to the account type and currency, and then generates the corresponding account details according to the account level, accounting subject and debit / credit direction.

[0039] The generation of customer account details revolves around the customer account number and currency. The accounting process reads the configuration of the account type as customer account from the accounting records and matches it with the account status data for the same customer account number and the same currency. After a successful match, the customer account number, account level, account type, lending direction, transaction amount, currency, balance before update, and previous balance verification value are written to the customer account details. The customer account details are used to record the direction and source of the customer's visible balance in this transaction.

[0040] The generation of virtual account details revolves around the virtual account number and currency. The accounting process reads the configuration of the account type as virtual account from the accounting records and matches the account status data with the same virtual account number and the same currency. The virtual account number originates from the segregated account identifier assigned to customers or business scenarios in the business ledger. After a successful match, the virtual account details are written with the corresponding account level, account type, lending direction, transaction amount, currency, balance before update, and previous balance verification value. The virtual account details are used to maintain the accounting association between the business segregated balance and the customer account balance.

[0041] The generation of detailed information at the internal account level revolves around accounting subjects and currencies. The accounting process reads the configuration of accounts designated as internal accounts from the accounting records and matches the internal account status in the account status data based on the accounting subject and currency. The accounting subjects, derived from the account configuration table, represent internal accounting objects such as inter-channel receivables and payables, commission income, and clearing and settlement transition funds. Upon successful matching, the internal account details are written with the accounting subject, account type, debit / credit direction, transaction amount, currency, previous balance, and previous balance verification value. These internal account details serve as input for subsequent balance model calculations and the generation of netting change records.

[0042] The main trading account details are generated by the main trading account configuration. The accounting process will label the customer account details, virtual account details, and internal account details generated by the main trading account configuration as main trading account details. The main trading account details inherit the transaction amount and currency corresponding to the main trade, while the fee account details inherit the fee amount and currency corresponding to the fee account configuration. Both types of details are distinguished by their source under the same ledger number. This label is used to subsequently merge the main trading details and fee details into the same accounting detail set.

[0043] When a valid transaction code for handling fees exists in the accounting records, the handling fee account configuration participates in the generation of handling fee account details. The handling fee account configuration is derived from the query results of the preceding account configuration table. The account status data provides the balances of the handling fee deduction account and the handling fee income account before the update. During generation, the handling fee deduction details at the customer account level are written with the lending / borrowing direction and fee amount according to the handling fee deduction configuration, while the handling fee income details at the internal account level are written with the accounting subject, lending / borrowing direction, and fee amount according to the handling fee income configuration. For example, with a deposit of USD 1000 and a handling fee of USD 5, the main trading account details will hold USD 1000, and the handling fee account details will hold USD 5.

[0044] Fee account details and main trading account details are grouped into the same ledger number and currency in the account details collection. The account details collection stores the customer account details, virtual account details, internal account details, and fee account details corresponding to this transaction. Subsequent balance calculations, cross-level lending difference calculations, and account details entries are all processed using the account details collection.

[0045] When the transaction code for handling fees in the accounting record is empty, the handling fee account details will not be included in the generation process. The accounting process directly groups customer account details, virtual account details, and internal account details into the accounting detail set according to the same ledger number and the same currency. The accounting detail set only carries the multi-level account details corresponding to the main transaction, and subsequent processing continues to be executed according to the same ledger number and the same currency.

[0046] The set of account details is used to form candidate detail groups. The accounting process filters customer account details, virtual account details, and internal account details from the set according to the ledger number and currency to generate candidate detail groups. Candidate detail groups are used to represent the correspondence between the customer account layer, virtual account layer, and internal account layer for the same transaction. Subsequent cross-layer borrowing and lending difference calculations use candidate detail groups as the verification object.

[0047] The candidate detail group undergoes integrity verification. The accounting process reads the account hierarchy and account type from the candidate detail group, verifying whether customer account details, virtual account details, and internal account details exist simultaneously. If all three types of details exist, the candidate detail group is determined as the detail group for cross-level lending and borrowing difference calculation and proceeds to the subsequent balance calculation and difference calculation processes. If any account detail is missing, the accounting process outputs a detail group exception record, which includes the ledger number, currency, missing account hierarchy, missing account type, and exception reason.

[0048] S4. The detailed account group enters the balance calculation stage. The accounting process reads the balance pattern and debit / credit direction carried by each account detail in the accounting detail set. Combined with... Figure 4 As shown, the balance pattern originates from the account configuration table and has been written into the accounting details set along with customer account details, virtual account details, and internal account details. The debit / credit direction originates from the accounting processing records and is used to determine the increase or decrease direction of the transaction amount on the corresponding account balance. Customer account details and virtual account details calculate the updated balance according to their respective balance patterns, while internal account details calculate the updated balance according to the balance pattern corresponding to the internal account. The calculation results are then included in the subsequent table writing and difference verification processes along with the account details.

[0049] In debit balance mode, the accounting process uses the pre-update debit balance as the calculation base. When the account details are debited, the transaction amount is added to the pre-update debit balance to obtain the updated account balance; when the account details are credited, the transaction amount is deducted from the pre-update debit balance to obtain the updated account balance. If the balance after deduction is less than zero, the accounting process outputs an insufficient balance exception record, and the corresponding account details are not entered into the account master table write process.

[0050] In the credit balance mode, the accounting process uses the pre-update credit balance as the calculation base. When the debit / credit direction of the account details is credit, the transaction amount is added to the pre-update credit balance to obtain the updated account balance; when the debit / credit direction of the account details is debit, the transaction amount is deducted from the pre-update credit balance to obtain the updated account balance. If the balance after deduction is less than zero, the accounting process outputs an insufficient balance exception record, and the corresponding account details are not entered into the account master table write process.

[0051] The two-way balance mode retains both the debit and credit balance fields. When the account details show a debit direction, the transaction amount is added to the original debit balance, while the original credit balance remains unchanged. When the account details show a credit direction, the transaction amount is added to the original credit balance, while the original debit balance remains unchanged. The updated balance generated under the two-way balance mode includes both the updated debit and credit balances, which are subsequently written to the main account table.

[0052] For account details with a netting balance mode and an internal account type, the accounting process filters the corresponding internal account details from the detail group. Filtering criteria include account type, balance mode, same ledger number, and same currency. Once a match is found, the accounting process reads the debit / credit direction, transaction amount, and the original debit and credit balances from the internal account details to form the pending netting details. The pending netting details record the original amount and original balance required for this netting calculation. Subsequent offsetting amounts, unoffset amounts, and netting change records are all calculated from the pending netting details.

[0053] The debit / credit direction in the pending reconciliation details is used to determine the offsetting balance. When the debit / credit direction is debit, the balance before the update (opposite to the debit / credit direction) is the credit balance before the update, and the accounting process uses the credit balance before the update as the offsetting balance. When the debit / credit direction is credit, the balance before the update (opposite to the debit / credit direction) is the debit balance before the update, and the accounting process uses the debit balance before the update as the offsetting balance. The offsetting balance is used to indicate the opposite balance that can be offset against the current transaction amount, reducing the situation where both debit and credit sides of the same internal account are simultaneously outstanding for a long time.

[0054] The offsetting balance and transaction amount are compared and calculated. When the transaction amount is less than or equal to the offsetting balance, the offsetting amount is the transaction amount, and the unoffset amount is zero. When the transaction amount is greater than the offsetting balance, the offsetting amount is the offsetting balance, and the unoffset amount is the difference between the transaction amount and the offsetting amount. The offsetting amount represents the amount absorbed by the opposite balance in this transaction, and the unoffset amount represents the amount that still needs to be transferred to the current lending direction after offsetting. The two amounts together constitute the netting calculation result.

[0055] When the debit / credit direction of the pending netting details is debit, the accounting process uses the pre-update credit balance as the offsetting balance and generates an offsetting amount based on the smaller of the transaction amount and the pre-update credit balance. The offsetting amount is then subtracted from the transaction amount to obtain the unoffset amount. For example, if the pre-update debit balance of an internal account is 0, the pre-update credit balance is 600, and the debit transaction amount is 1000, the offsetting amount is 600, and the unoffset amount is 400. The pre-update credit balance corresponding to this pending netting detail is first offset to 0, and the unoffset amount is transferred to the debit balance.

[0056] The debit netting calculation result is used to update the balances on both the debit and credit sides. The accounting process deducts the pre-update credit balance from the offset amount and adds the pre-update debit balance to the unoffset amount. Using the aforementioned values, the updated credit balance is 0, and the updated debit balance is 400. The generated updated debit and credit balances serve as the balance results for this internal account after this transaction and are entered into the netting change record writing process.

[0057] When the debit / credit direction of the pending netting details is credit, the accounting process uses the pre-update debit balance as the offsetting balance and generates an offsetting amount based on the smaller of the transaction amount and the pre-update debit balance. Then, the offsetting amount is subtracted from the transaction amount to obtain the unoffset amount. This unoffset amount is then subtracted from the pre-update debit balance, and the unoffset amount is used to increase the pre-update credit balance. This process generates the updated debit and credit balances after credit netting, which serve as the internal account balance results for credit transactions.

[0058] The netting calculation results are written to the netting change record. The accounting process writes the debit balance before the update, the credit balance before the update, the offset amount, the unoffset amount, the debit balance after the update, and the credit balance after the update into the netting change record. The netting change record is included in the account details table along with the internal account details. Subsequent writing to the main account table, balance verification value generation, and reversal recovery all read from this record. By retaining the balances before and after the update and the offsetting process, the accounting process can restore the corresponding account balance status according to the original transaction's netting path when reversing.

[0059] S5, detailed group, and netting change records enter the cross-level lending and borrowing difference calculation stage. Combined with... Figure 5 As shown, the detail groups originate from customer account details, virtual account details, and internal account details under the same ledger number and currency. The netting change records originate from the netting calculation results of previous internal accounts. The participation flag in the account configuration table serves as the filtering criterion; account details with a value of [value] participate in the netting calculation, while account details with a value of [value] do not participate and are only retained in the accounting detail set for writing into the account detail table.

[0060] Once the account details involved in the difference calculation are determined, the accounting process summarizes the transaction amounts separately according to the debit and credit directions. Account details with a debit direction are included in the debit amount summary, and account details with a credit direction are included in the credit amount summary. The same ledger number and the same currency are limited to the same transaction and the same currency balance to prevent amounts from different transactions or different currencies from being mixed in the same difference calculation process. After the debit and credit amounts are summarized, the accounting process subtracts the credit amount from the debit amount to obtain the cross-level debit / credit difference. When the cross-level debit / credit difference is zero, it indicates that the debit and credit balances of the account details involved in the difference calculation under the same ledger number and the same currency are balanced; when the cross-level debit / credit difference is not zero, it indicates that there is a debit / credit imbalance among the account details involved in the difference calculation.

[0061] Cross-level debit / credit difference is used to determine whether account details under the same account number, identified by the account configuration table as participating in the difference calculation, maintain a debit / credit balance. Taking a deposit transaction as an example, when the account configuration table marks customer account details and internal account details as participating in the difference calculation, the customer account details will generate a credit entry of 1000 USD, and the internal account details will generate a debit entry of 1000 USD. When virtual account details are marked as not participating in the difference calculation, they are only retained in the account details set for writing to the account details table and are not included in this cross-level debit / credit difference calculation. At this time, the debit entry and credit entry are equal, the cross-level debit / credit difference is zero, and the accounting process enters the account master table write preparation stage; when the debit entry and credit entry are not equal, the accounting process enters the abnormal output stage.

[0062] When the cross-level debit / credit difference is zero, the accounting process generates a current balance verification value for each account detail. The current balance verification value identifies the continuity between the current balance update and the previous balance status, and its data is carried by the account master table and the account detail table. During generation, the accounting process combines the previous balance verification value, account number, currency, updated balance, detail serial number, and the offset and unoffset amounts from the netting change record in a fixed field order. Then, a hash operation is performed on the combined data to obtain the current balance verification value. For example, when generating the current balance verification value for internal account netting details, the field combination order is: previous balance verification value, account number, currency, updated debit balance, updated credit balance, detail serial number, offset amount, and unoffset amount. For account details in non-netting balance mode, the current balance verification value is generated using the previous balance verification value, account number, currency, updated balance, and detail serial number.

[0063] The current balance verification value and the updated balance are both written to the account master table. The accounting process locates the write record in the account master table according to the account number and currency; when the balance mode is debit balance mode or credit balance mode, the corresponding one-sided balance field is written; when the balance mode is two-way balance mode or netting balance mode, the updated debit balance and the updated credit balance are written respectively. The current balance verification value synchronously overwrites the previous balance verification value field in the account master table, serving as the source of the previous balance verification value when reading the account status for the next transaction.

[0064] Once the account master table is written, the accounting process writes the corresponding set of accounting details and netting change records to the account detail table. The account detail table stores each account detail according to the ledger number, account number, currency, and detail serial number. Each account detail includes the debit / credit direction, transaction amount, balance before update, balance after update, previous balance verification value, and current balance verification value. For internal account details with netting change records, the following are simultaneously written: previous debit balance, previous credit balance, offset amount, unoffset amount, and updated debit and credit balances. After the account detail table is written, the accounting process outputs the accounting processing results, which include the ledger number, currency, successfully written account details, account master table update status, and current balance verification value.

[0065] When the cross-level debit / credit difference is not zero, the accounting process stops writing to the main account table and outputs an accounting exception record based on the detail group and the cross-level debit / credit difference. The accounting exception record includes the ledger number, currency, debit amount, credit amount, cross-level debit / credit difference, the range of account details involved in the difference calculation, and the reason for the exception. This is used to locate errors in the amount direction, missing configurations, or duplicate entries in customer account details, virtual account details, or internal account details. The formal account details corresponding to this balance update are not written to the account details table.

[0066] S6. After the accounting processing results are output, when the cross-border payment platform receives a reversal instruction initiated by the channel callback, manual review, or business ledger, the accounting processing flow enters the reversal processing stage. Combined with... Figure 5 As shown, the reversal instruction carries a ledger number, which is consistent with the ledger number saved when the original transaction was written to the account details table. The accounting process first uses the ledger number as a search condition to locate the account details corresponding to the original transaction in the account details table, and then reads the netting change record bound to the original transaction. The netting change record saves the balance before the update, the amount offset, the amount not offset, and the balance after the update when the original transaction occurred, serving as the data source for subsequently restoring the account balance status.

[0067] The netting change record corresponding to the original transaction is read, and the accounting process reads the current balance and current balance verification value of the corresponding account from the account master table. The corresponding account is determined by the account number and currency in the original transaction account details; when the balance mode is the netting balance mode, the current balance includes the current debit balance and the current credit balance, and the current balance verification value comes from the verification field saved after the most recent balance update in the account master table. The accounting process merges the results read from the account details table and the account master table to generate the data of accounts to be reversed, and the data of accounts to be reversed enters the balance verification value continuity verification process.

[0068] The balance verification values ​​in the account details table are arranged in the order they were written. The accounting process starts with the current balance verification value saved in the original transaction account details and ends with the current balance verification value in the account master table for continuity verification. During verification, the process first reads the details records from the next account detail after the original transaction account detail to the latest account detail under the same account number and currency. Then, it checks the previous balance verification value of the next account detail one by one according to the detail serial number or the order of writing time. If the current balance verification value of the last account detail matches the current balance verification value in the account master table, the continuity verification passes. For example, if the current balance verification value of the original transaction account detail is H1, the previous balance verification value of the next account detail is H1 and the current balance verification value is H2, and the previous balance verification value of the next account detail is H2 and the current balance verification value is H3, and the current balance verification value in the account master table is H3, the continuity verification passes. If there are no subsequent account details after the original transaction account details, the accounting process directly compares the current balance verification value saved in the original transaction account details with the current balance verification value in the account master table. If the two are consistent, the continuity verification passes.

[0069] If the continuity check passes, the accounting process generates a reversal and recovery instruction. This instruction includes the ledger number, account number, currency, the netting change record identifier corresponding to the original transaction, the current balance verification value, and the reversal processing status. This serves as the basis for subsequently restoring the corresponding account balance. Taking the deposit transaction with ledger number BOOK20260001 as an example, the netting change record corresponding to the original transaction stores the amount deducted and not deducted in the internal account for this deposit. After the continuity check passes, the accounting process can confirm that the balance verification chain between the account details table and the account master table is not broken before proceeding with the balance recovery process.

[0070] If the continuity check fails, the accounting process outputs a reversal exception record. This record includes the ledger number, account number, currency, the balance verification value corresponding to the original transaction, the current balance verification value in the account master table, the break point, and the reason for the exception. The break point is determined by the details of the unconnected adjacent accounts. When a reversal exception record exists, the accounting process does not perform account balance restoration to avoid writing a reversal result when the account master table and account detail table are inconsistent.

[0071] The reversal recovery instruction is used to trigger the reverse recovery process. The accounting process reads the pre-update balance, offset amount, unoffset amount, and updated balance from the netting change record, and performs reverse recovery according to the original transaction's netting path. Before the recovery process is executed, the accounting process first determines the deduction side balance based on the original transaction's debit / credit direction; if the original transaction's debit / credit direction is debit, the deduction side balance is the current debit balance; if the original transaction's debit / credit direction is credit, the deduction side balance is the current credit balance. If the deduction side balance is less than the unoffset amount formed by the original transaction, the accounting process outputs a reversal exception record and does not perform account balance recovery; if the deduction side balance is greater than or equal to the unoffset amount formed by the original transaction, the accounting process continues to perform reverse recovery.

[0072] Reverse recovery follows the offsetting process saved in the original transaction. If the original transaction was a debit, the recovery process deducts the unoffset amount from the current debit balance and adds the original transaction's offsetting amount to the current credit balance. If the original transaction was a credit, the recovery process deducts the unoffset amount from the current credit balance and adds the original transaction's offsetting amount to the current debit balance. Taking the aforementioned internal account debit transaction as an example, if the original transaction record shows an offsetting amount of 600 and an unoffset amount of 400, the reverse recovery deducts 400 from the current debit balance and adds 600 to the current credit balance. The recovery process reads the original netting change record and does not recalculate the offsetting amount based on the current balance.

[0073] The restored account balance is used to generate the post-reversal balance verification value. During generation, the current balance verification value, account number, currency, restored debit balance, restored credit balance, reversal detail serial number, and original netting change record identifier are combined in a fixed field order. A hash operation is then performed on the combined data to obtain the post-reversal balance verification value. The accounting process writes the restored account balance and the post-reversal balance verification value into the account master table, and saves the reversal account details, original netting change record identifier, balance before restoration, restored account balance, previous balance verification value, and post-reversal balance verification value to the account details table.

[0074] After the reversal is completed, the accounting process outputs the reversal result. The reversal result includes the ledger number, account number, currency, restored account balance, post-reversal balance verification value, reversal transaction number, and processing status. This result is returned to the business ledger and channel callback process to mark that the original transaction has been restored and to provide a new preceding balance verification value for subsequent balance updates of the same account.

[0075] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A transaction code-driven multi-level accounting method, characterized in that, include: S1. Obtain cross-border payment transaction requests and account configuration tables. Parse the transaction code, ledger number, transaction amount, currency and original transaction code from the cross-border payment transaction requests. Match the account level, account type, accounting subject, debit / credit direction and balance mode in the account configuration table according to the transaction code, and generate accounting processing records. S2. Based on the accounting records, read the corresponding customer account status, virtual account status and internal account status, obtain the balance before the update and the previous balance verification value of each account, and generate account status data. S3. Generate customer account details, virtual account details, and internal account details based on accounting records and account status data, and summarize them into an accounting details set; S4. Calculate the updated balance of the corresponding account based on the balance pattern of each account detail in the accounting detail set. For internal account details in the accounting detail set with the balance pattern of netting balance, calculate the offset amount and the unoffset amount of the opposite balance based on the debit / credit direction, transaction amount and the balance of the internal account before the update, and generate a netting change record containing the balance before the update, the offset amount, the unoffset amount and the updated balance. S5. Based on the account details identified by the account configuration table under the same ledger number and the same currency as those participating in the difference calculation, calculate the cross-level debit and credit difference between the debit and credit amounts. When the cross-level debit and credit difference is zero, generate the current balance verification value based on the netting change record and the previous balance verification value. Write the updated balance and the current balance verification value into the account master table, write the accounting details set and the netting change record into the account details table, and output the accounting processing results. S6. When a reversal instruction for a ledger number is received, read the netting change record and the current balance verification value corresponding to the original transaction. According to the writing order of the balance verification values ​​in the account details table, check whether the current balance verification value is continuous with the balance verification value corresponding to the original transaction. If they are continuous, restore the corresponding account balance status according to the netting change record and output the reversal processing result.

2. The method according to claim 1, characterized in that, The transaction code processing record generated in S1 includes: S1.1 Obtain the transaction code mapping table and the transaction code. Match the transaction code with the corresponding commission transaction code and reversal transaction code from the transaction code mapping table, and generate a transaction code matching result containing the transaction code, commission transaction code and reversal transaction code. S1.

2. Based on the transaction code matching results, ledger number and original transaction code, group the transaction code, handling fee transaction code and reversal transaction code under the same ledger number and generate a transaction code processing record with the original transaction association information.

3. The method according to claim 2, characterized in that, In step S1, the account level, account type, accounting subject, debit / credit direction, and balance mode are matched in the account configuration table based on the transaction code, including: S1.3 Obtain the transaction code processing record and account configuration table. Based on the transaction code and commission transaction code in the transaction code processing record, query the account configuration table to generate the main trading account configuration and commission account configuration. S1.

4. Based on the main trading account configuration and the commission account configuration, verify whether the account configuration under the same ledger number includes account level, account type, accounting subject, debit / credit direction and balance mode, and generate configuration verification results; S1.5 When the configuration verification result is passed, generate accounting records based on the main trading account configuration, handling fee account configuration, ledger number, transaction amount and currency. When the configuration verification result is failed, output configuration exception records.

4. The method according to claim 3, characterized in that, The account status data generated in S2 includes: S2.1 Obtain accounting records, determine the reading path of customer accounts, virtual accounts and internal accounts according to the account type in the accounting records, and read the corresponding account status according to the customer account number, virtual account number or accounting subject and currency, and generate the account status to be verified. S2.

2. Perform a locked read on the account status to be verified, obtain the balance before the update, the previous balance verification value in the account master table, and the latest balance verification value in the account details table for each account status, and generate the locked account status. S2.

3. Compare the previous balance check value and the latest balance check value in the locked account status. If they match, output the previous balance and the previous balance check value as account status data. If they do not match, output an account status exception record.

5. The method according to claim 4, characterized in that, The S3 process generates a set of detailed accounting records, including: S3.1 Obtain accounting records and account status data. Based on the account level, account type, accounting subject, debit / credit direction, transaction amount and currency in the accounting records, match the account status data to customer accounts, virtual accounts and internal accounts respectively, and generate customer account details, virtual account details and internal account details. S3.2 When the accounting records include a transaction fee code, generate transaction fee account details based on the transaction fee account configuration and account status data corresponding to the transaction fee code, and classify the transaction fee account details and the main transaction account details into the same ledger number and the same currency of the accounting details set. S3.3 When the accounting records do not include the transaction fee code, the customer account details, virtual account details and internal account details shall be grouped into the same ledger number and the same currency of the accounting details set.

6. The method according to claim 5, characterized in that, The S3 section describes the grouping of the account details set, including: S3.4 Obtain the set of account details, and filter customer account details, virtual account details, and internal account details from the set of account details according to the ledger number and currency to generate candidate detail groups; S3.

5. Based on the account level and account type in the candidate detail group, verify whether the candidate detail group contains customer account details, virtual account details, and internal account details. If it contains them, determine the candidate detail group as the detail group for cross-level loan difference calculation. If any account detail is missing, output the detail group abnormal record.

7. The method according to claim 6, characterized in that, The S4 process generates a rolling difference change record, including: S4.1 Obtain the detail group, filter the internal account details with the balance mode of netting balance mode and the account type of internal account from the detail group, and read the debit and credit directions, transaction amounts, debit balance before update and credit balance before update from the internal account details to generate the details to be netted; S4.

2. Based on the details to be netted, the balance before the update that is opposite to the debit / credit direction is taken as the offsetting balance, and the offsetting amount and the unoffset amount are calculated based on the transaction amount and the offsetting balance to generate the netting calculation result; S4.

3. Based on the netting calculation results, determine the updated debit balance and the updated credit balance, and write the original debit balance, the original credit balance, the offset amount, the unoffset amount, the updated debit balance, and the updated credit balance into the netting change record.

8. The method according to claim 7, characterized in that, The calculation of the offset amount and the unoffset amount based on the transaction amount and the offset balance in S4 includes: S4.4 When the debit / credit direction of the details to be netted is debit, generate the offset amount based on the smaller value between the transaction amount and the credit balance before the update, and generate the unoffset amount based on the difference between the transaction amount and the offset amount. S4.

5. Based on the offset amount, deduct the pre-update credit balance and based on the unoffset amount, increase the pre-update debit balance to generate the updated debit balance and updated credit balance after debit netting. S4.6 When the debit / credit direction of the details to be netted is credit, generate the offset amount based on the smaller of the transaction amount and the debit balance before the update, and generate the unoffset amount based on the difference between the transaction amount and the offset amount. Then, deduct the debit balance before the update based on the offset amount and increase the credit balance before the update based on the unoffset amount to generate the updated debit balance and the updated credit balance after credit netting.

9. The method according to claim 8, characterized in that, The accounting processing results output in S5 include: S5.

1. Obtain the detail group and netting change records. Based on the debit and credit directions and transaction amounts of the account details in the detail group that are determined by the account configuration table to participate in the difference calculation, summarize the debit and credit amounts under the same ledger number and the same currency, and calculate the difference between the debit and credit amounts to generate cross-level debit and credit differences. S5.2 When the cross-level lending difference is zero, generate the current balance verification value based on the netting change record, the updated balance and the previous balance verification value, and write the updated balance and the current balance verification value into the account master table; S5.3 Write the detail group and netting change records into the account detail table and output the accounting processing results; when the cross-level debit and credit difference is not zero, do not execute the write to the account master table, and output the accounting exception record according to the detail group and cross-level debit and credit difference.

10. The method according to claim 9, characterized in that, The output of the correction processing result in S6 includes: S6.1 Obtain the ledger number in the reversal instruction, read the netting change record corresponding to the original transaction from the account details table based on the ledger number, and read the current balance and current balance verification value of the corresponding account from the account master table to generate the data of the account to be reversed; S6.

2. Based on the balance verification values ​​arranged in the order of writing in the account details table, perform a continuity check between the current balance verification value and the balance verification value corresponding to the original transaction. If the continuity check passes, generate a reversal recovery instruction; if the continuity check fails, output a reversal exception record. S6.

3. Based on the reversal recovery instruction and the balance before update, the amount offset, the amount not offset, and the balance after update in the netting change record, reverse the balance status of the corresponding account, generate the reversal balance verification value based on the restored account balance, and output the reversal processing result.

Images