Reconciliation method and system, and related device

Abstract

The present application provides a reconciliation method and system, and a related device. The method comprises the following steps: acquiring transaction data of multiple transactions from a payment channel system; determining a billing result of the payment channel cost for each transaction on the basis of a billing model; receiving a deduction result, fed back by a bank system, of the payment channel cost for each transaction; consolidating billing results of the multiple transactions to obtain a consolidated billing result; consolidating deduction results of the multiple transactions to obtain a consolidated deduction result; determining the difference value between the consolidated billing result and the consolidated deduction result; and when the difference value exceeds an early warning threshold, sending early warning information to a user to instruct the user to update the billing model, so that when a channel cost reconciliation error occurs, the user updates the billing model, improving the reconciliation efficiency, and reducing the labor costs, thus improving the user experience.

Description

A reconciliation method, system and related equipment

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on February 1, 2024, with application number 202410146102.8, and priority to the Chinese patent application entitled “A Reconciliation Method, System and Related Equipment”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computers, and in particular to a reconciliation method, system, and related equipment. Background Art

[0003] A third-party payment platform is a company or institution that provides a settlement channel between buyers and sellers. Under this model, buyers select and purchase goods and pay the third-party payment platform. The third-party payment platform then notifies the seller of the goods for shipment. Once the buyer confirms receipt, the third-party payment platform transfers the payment to the seller's account, completing the transaction. Third-party payment platforms integrate multiple payment channels, such as online banking, mobile QR codes, and bank cards, to accommodate the diverse payment habits of both buyers and sellers.

[0004] However, for every transaction a user makes through a payment channel, the third-party payment platform must pay a fee to the payment channel company. Therefore, the third-party payment platform must maintain a separate channel cost bill to record the channel fee payable for each transaction. This bill must also be compared with the channel debit bill provided by the bank. This process is also known as channel cost reconciliation. If the payable and actual fees are consistent, the bill can be reconciled. If not, financial staff must investigate the cause and adjust the channel cost bill. Third-party payment platforms can handle tens of thousands of transactions per day, requiring a large staff to individually adjust problematic bills. This not only results in high labor costs and low reconciliation efficiency, but also relies heavily on staff expertise, impacting the accuracy and timeliness of the third-party payment platform's general ledger. Summary of the Invention

[0005] The present application provides a reconciliation method, system and related equipment for solving the problem that channel cost reconciliation requires a large number of employees to adjust problematic bills one by one, resulting in high labor costs and low reconciliation efficiency.

[0006] In a first aspect, a reconciliation method is provided, which is applied to a reconciliation system, and includes the following steps: obtaining transaction data of multiple transactions from a payment channel system, determining a billing result of the payment channel cost of each transaction based on a billing model, the billing model including billing elements and corresponding billing rules, the billing elements are used to determine the billing rules used when performing channel cost billing on transaction data, the correspondence between the billing elements and the billing rules is configured by the user through a visual interface, obtaining a deduction result of the payment channel cost of each transaction from a bank system, merging the billing results of multiple transactions to obtain a merged billing result, merging the deduction results of multiple transactions to obtain a merged deduction result, determining a difference between the merged billing result and the merged deduction result, and sending a warning message to the user when the difference exceeds a warning threshold, the warning message being used to instruct the user to update the billing model.

[0007] By implementing the method described in the first aspect, the reconciliation system can obtain transaction data of multiple transactions from the payment channel system, determine the billing result of the payment channel cost of each transaction based on the billing model, and then obtain the deduction result of the payment channel cost of each transaction from the bank system, and then merge the billing results of multiple transactions to obtain a merged billing result, merge the deduction results of multiple transactions to obtain a merged deduction result, determine the difference between the merged billing result and the merged deduction result, and when the difference exceeds the warning threshold, send a warning message to the management user to instruct the user to update the billing model, so that the channel cost can be reconciled in a consolidated reconciliation, without the need to reconcile one by one, thereby improving the reconciliation efficiency. At the same time, the management user can update the billing model according to the warning information, and no longer need to adjust the problematic transactions one by one, thereby improving the reconciliation efficiency, reducing labor costs, and improving the user experience.

[0008] In a possible implementation, the method further includes the following steps: when the difference does not exceed the warning threshold, performing a write-off operation on the channel costs of the multiple transactions.

[0009] In the above implementation, when the difference between the consolidated accounting result and the consolidated deduction result is small, multiple transactions can be directly written off. It should be understood that after the consolidated accounting, if the difference between multiple transactions is small, for example, the difference between 1,000 transactions is 1 cent, it means that the reason for the reconciliation failure can be ignored. After directly writing off the 1,000 transactions, the user does not need to verify the reason for the 1 cent difference in each of the 1,000 transactions, thereby reducing labor costs and improving reconciliation efficiency.

[0010] In one possible implementation, when obtaining transaction data of multiple transactions and determining the billing result of the payment channel cost of each transaction based on a billing model, the transaction data of multiple transactions can be first obtained, and multiple transaction attributes of each transaction can be determined. The transaction attributes are used to describe the transaction data. Then, based on the multiple transaction attributes of each transaction, a transaction attribute table is generated. The transaction attribute table includes multiple fields, each field represents a transaction attribute, and each row of data in the transaction attribute table corresponds to a batch of transaction data with multiple identical transaction attributes. The billing model corresponding to each batch of transaction data is determined based on the transaction attributes. Based on the billing model corresponding to each batch of transaction data, the billing result of the channel cost corresponding to each transaction data in each batch of transaction data is determined.

[0011] Furthermore, since the amount of transaction data is often very large, in order to ensure efficient data query, an index can be assigned to each batch of transaction data. Specifically, an additional index field can be maintained in the transaction attribute table. The index can be the hash value of multiple fields, so that each row of data can correspond to an index. Using the index, each row of transaction data can be queried, thereby improving the efficiency of data query.

[0012] Furthermore, if multiple rows of transaction data with the same hash value exist, the rows corresponding to the same hash value can be concatenated into a linked list, with each row corresponding to a node in the linked list. Specifically, an additional field for identifying the linked list nodes can be maintained in the transaction attribute table, such as a linked list node sequence or a preceding node sequence. This allows multiple rows of transaction data with the same hash value to be concatenated into a linked list, with each row corresponding to a different linked list node. This allows querying data by first reading the entire linked list corresponding to the hash value, then traversing the transaction data corresponding to each linked list node in sequence according to the node order described by the linked list node field, until finding transaction data that meets the query criteria. This avoids index invalidation due to hash conflicts. The linked list nodes can be arranged in the order in which they were added.

[0013] The above implementation method can merge multiple transactions with the same transaction attributes through the transaction attribute table, so that a row of data in the transaction attribute table can be charged using the same billing rule, thereby improving billing efficiency.

[0014] In one possible implementation, the reconciliation system includes multiple billing bitmaps, wherein one billing result corresponds to one billing bitmap, the billing bitmap includes multiple bits, each bit corresponds to a billing attribute, the value of each bit is used to indicate whether the corresponding billing attribute exists in the corresponding billing result, and the billing attribute is used to describe the billing result.

[0015] Furthermore, each bitmap may correspond to a detailed list, where the bitmap is used to record the billing attributes contained in the billing result, and the detailed list is used to record the values ​​corresponding to the billing attributes. For example, the bitmap includes 5 bits, the first bit represents the network service, the second bit represents the brand fee, the third bit represents the bank fee, the fourth bit represents the business participation price (some specific businesses require participants to pay additional fees, such as entrance fees, membership fees, etc.), and the fifth bit represents the promotion fee. If the billing result includes a total channel cost of 5 yuan, including 1 yuan for network service fee, 2 yuan for brand fee, and 2 yuan for bank fee, then the bitmap of the billing result can be: (1,1,1,0,0), and the detailed list corresponding to the bitmap includes a network service fee of 1 yuan, a brand fee of 2 yuan, and a bank fee of 2 yuan. It should be understood that the above examples are for illustration and are not specifically limited in this application.

[0016] The above implementation method records the billing attributes contained in the billing results of each transaction in the form of a bitmap, and then records the specific value of each billing attribute through a detailed table. Under this implementation method, the bitmap can not only effectively save storage space, but also quickly filter out billing results that meet specific billing attributes through masks, bit operations, etc. The retrieval method is faster, which improves data query efficiency. At the same time, the bitmap is also easy to expand. When adding new billing attributes, the new billing attributes can be supported by expanding the bitmap and detailed table without modifying the entire data structure, making the billing results easier to maintain.

[0017] In one possible implementation, when merging the billing results of multiple transactions to obtain a merged billing result, one or more merged billing attributes can be obtained first, and based on the one or more merged billing attributes and multiple billing bitmaps, the multiple transactions can be divided into multiple merged groups, wherein multiple transactions in a merged group include the same merged billing attribute, the billing results of the multiple transactions in each merged group are merged to obtain the billing result of each merged group, and the merged billing result of the multiple transactions is obtained based on the billing results of each merged group.

[0018] In a specific implementation, when multiple transactions are divided into multiple merged groups based on one or more merged billing attributes and multiple billing bitmaps, one or more masks can be determined based on the one or more merged billing attributes, and then the one or more masks can be applied to multiple billing bitmaps to obtain multiple merged groups containing one or more merged billing attributes. A mask can be generated based on the merged billing attributes, and the mask can be used to perform a bitwise AND operation on the bitmap. If the result of the bit after the operation is non-zero, it means that the billing result contains the billing attribute represented by the bit. If the result of the bit after the operation is zero, it means that the billing result contains the billing attribute represented by the bit. Based on the result of the mask operation, a bitmap that meets the conditions can be obtained, and then based on the detailed table corresponding to the bitmap, multiple billing results that meet the merged billing attributes can be obtained, and then the merged accounting result can be obtained.

[0019] In a specific implementation, after obtaining the billing results of each merged group through a bitmap, when merging the billing results of multiple transactions in the merged group, the channel costs of the multiple transactions can be merged first to obtain a merged billing amount. Then, based on the merged billing amount, a merged accounting result can be generated. The merged accounting result includes the merged billing amount and other information. The merged billing amount includes the total channel cost amount of the multiple transactions and the total amount of multiple categories. A category can be a certain type of handling fee in the multiple transactions, such as the total clearing fee, the total settlement fee, the total network fee, the total technical support fee, the total risk management fee, the total compliance and regulatory fee, the total promotion and duration fee, the total brand fee, etc. A category can also be a merged handling fee selected by a certain billing attribute in the multiple transactions, such as calculating the total channel cost payable to Bank A in the multiple transactions, calculating the total brand fee payable at time T1-T2 in the multiple transactions, etc., or calculating the total channel cost of the multiple transactions with the transaction status of "completed". The specific details can be determined according to actual business needs and are not specifically limited in this application. Other information may include transaction information, such as the transaction time, transaction number, transaction amount, payment channel, transaction status, etc. of each transaction; the consolidated accounting results may also include billing results, such as the billing results, billing rules, billing time, etc. of each transaction; the consolidated accounting results may also include consolidated information, such as the consolidated date, the consolidated number of transactions, the consolidated total amount, etc.; the consolidated accounting results may also include channel cost information, such as the channel name, channel fees, the consolidated total amount of channel costs, etc.; the consolidated accounting results may also include total information, such as the total number of transactions, the total transaction amount, the total billing amount, the total channel cost, etc. The above examples are for illustration only. The consolidated accounting results may also include more content, which can be determined based on the business needs during the actual channel cost reconciliation. This application does not make any specific limitations.

[0020] It should be noted that the reconciliation system can be pre-configured with template information for the consolidated accounting results. This template information includes some necessary fields for the consolidated accounting results, such as the transaction information, billing results, consolidated information, channel cost information, and total information described above. In this way, the reconciliation system obtains various consolidated amounts based on the required fields in the template information, fills in the fields, and generates the consolidated accounting results.

[0021] This implementation reads the billing results of a consolidated group based on the consolidated billing attributes, then consolidates the billing results of multiple transactions within the consolidated group. This allows users to flexibly read billing results from different consolidated groups by configuring the consolidated billing attributes. This allows for flexible reconciliation based on business needs, improving the user experience. Furthermore, due to the existence of the billing bitmap, regardless of changes to the consolidated billing attributes, multiple eligible transactions can be read from the billing bitmap using a mask. This allows for flexible, accurate, and fast reading, thereby improving reconciliation efficiency.

[0022] In one possible implementation, the billing results of multiple transactions in each merged group are merged. When the merged result of each merged group is obtained, multiple single billing results of the multiple transactions in each merged group can be sent to different instances for processing to obtain the completed merged result of each instance, where the instance includes a physical machine, a virtual machine or a container, and the number of transactions in each merged group is determined according to the processing capacity of each instance.

[0023] Optionally, the reconciliation system can be based on a big data platform, and can screen out multiple groups of billing results according to the combined billing attributes, and then merge the multiple groups of billing results to obtain multiple combined billing results. The above-mentioned big data platform may include but is not limited to hivesql, saprksql, etc. Specifically, batch processing or stream processing can be used to obtain multiple billing results, transaction attribute tables, bitmaps and other data and store them in the data warehouse of big data platforms such as hive and spark. Big data platforms such as hive and saprk provide SQL-like query languages ​​to facilitate complex data analysis, so that the big data platform can screen out multiple groups of billing results according to different combined billing attributes, complete the merger of multiple billing results of each merged group, and generate a merged billing result.

[0024] Optionally, the reconciliation system can establish a microservice architecture, through which billing consolidation tasks are assigned to various instances. One billing consolidation task is used to merge multiple billing results of a merge group. The microservice architecture includes multiple instances, each of which is used to perform a specific task. Each instance can run on a physical machine, a virtual machine, or a container. Furthermore, the microservice architecture can be combined with sharding stream technology to generate multiple billing consolidation tasks based on the merged billing attributes. These multiple billing consolidation tasks are then assigned to various microservice instances, allowing multiple instances to complete multiple billing consolidation tasks in parallel.

[0025] The above implementation method distributes the merging tasks to different instances for processing, and each instance processes the merging tasks in parallel, which can improve the processing efficiency of the merged billing results. In addition, the sharding flow technology can reasonably distribute the billing merging tasks to ensure that the processing pressure of each billing merging task is moderate, avoiding excessive processing burden of a single billing merging task. The microservice architecture can realize dynamic expansion and contraction of instances, and automatically adjust the number of instances according to the billing merging tasks to better meet business changes and development.

[0026] In one possible implementation, when merging the deduction results of multiple transactions to obtain a combined deduction result, the deduction results of multiple transactions in each combined group can be first merged to obtain the deduction result of each combined group, and then the combined billing result of multiple transactions can be obtained based on the deduction result of each combined group. In this way, when determining the difference between the combined billing result and the combined deduction result, the difference between the deduction result and the billing result of each combined group can be determined.

[0027] The above implementation method merges the deduction results in the same way to obtain the combined deduction results, and then compares the combined billing results of the same combined group with the combined deduction results, completing the channel cost reconciliation of the entire combined group at one time. Users do not need to check the billing results and deduction results one by one, thereby improving the efficiency of channel cost reconciliation.

[0028] On the second aspect, a reconciliation system is provided, which includes a single billing unit for obtaining transaction data of multiple transactions from a payment channel system, and determining the billing result of the payment channel cost of each transaction based on a billing model. The billing model includes billing elements and corresponding billing rules. The billing elements are used to determine the billing rules used when channel cost billing is performed on transaction data. The correspondence between the billing elements and the billing rules is configured by the user through a visual interface. A receiving unit is used to obtain the deduction result of the payment channel cost of each transaction from a bank system. A first merging unit is used to merge the billing results of multiple transactions to obtain a merged billing result. A second merging unit is used to merge the deduction results of multiple transactions to obtain a merged deduction result. A reconciliation unit is used to determine the difference between the merged billing result and the merged deduction result. An analysis unit is used to send an early warning message to the user when the difference exceeds the early warning threshold. The early warning message is used to instruct the user to update the billing model.

[0029] Implementing the system described in the second aspect, the reconciliation system can obtain transaction data of multiple transactions from the payment channel system, determine the billing result of the payment channel cost of each transaction based on the billing model, and then obtain the deduction result of the payment channel cost of each transaction from the bank system, and then merge the billing results of multiple transactions to obtain a merged billing result, merge the deduction results of multiple transactions to obtain a merged deduction result, determine the difference between the merged billing result and the merged deduction result, and when the difference exceeds the warning threshold, send a warning message to the management user to instruct the user to update the billing model, so that consolidated reconciliation can be performed when reconciling channel costs, and there is no need to reconcile one by one, thereby improving reconciliation efficiency. At the same time, the management user can update the billing model according to the warning information, and there is no need to adjust the problematic transactions one by one, thereby improving reconciliation efficiency, reducing labor costs, and improving user experience.

[0030] In a possible implementation, the analysis unit is configured to perform a write-off operation on the channel costs of the multiple transactions when the difference does not exceed a warning threshold.

[0031] In one possible implementation, a single-transaction billing unit is used to obtain transaction data of multiple transactions and determine multiple transaction attributes of each transaction. The transaction attributes are used to describe the transaction data. The single-transaction billing unit is used to generate a transaction attribute table based on the multiple transaction attributes of each transaction. The transaction attribute table includes multiple fields, each field represents a transaction attribute, and each row of data in the transaction attribute table corresponds to a batch of transaction data with multiple identical transaction attributes; the single-transaction billing unit is used to determine the billing model corresponding to each batch of transaction data based on the transaction attributes. The single-transaction billing unit is used to determine the billing result of the channel cost corresponding to each transaction data in each batch of transaction data based on the billing model corresponding to each batch of transaction data.

[0032] In one possible implementation, the reconciliation system includes multiple billing bitmaps, wherein one billing result corresponds to one billing bitmap, the billing bitmap includes multiple bits, each bit corresponds to a billing attribute, the value of each bit is used to indicate whether the corresponding billing attribute exists in the corresponding billing result, and the billing attribute is used to describe the billing result.

[0033] In one possible implementation, the first merging unit is used to obtain one or more merged billing attributes, and based on the one or more merged billing attributes and multiple billing bitmaps, divide multiple transactions into multiple merged groups, wherein multiple transactions in a merged group include the same merged billing attributes. The first merging unit is used to merge the billing results of the multiple transactions in each merged group to obtain the billing result of each merged group. The first merging unit is used to obtain the merged billing result of the multiple transactions based on the billing result of each merged group.

[0034] In one possible implementation, the first merging unit is used to determine one or more masks based on one or more merged billing attributes, and the first merging unit is used to apply the one or more masks to multiple billing bitmaps to obtain multiple merged groups containing one or more merged billing attributes.

[0035] In one possible implementation, the first merging unit is used to send multiple single billing results of multiple transactions in each merged group to different instances for processing to obtain the merged results completed by each instance, where the instance includes a physical machine, a virtual machine or a container, and the number of transactions in each merged group is determined according to the processing capacity of each instance.

[0036] In one possible implementation, the second merging unit is used to merge the deduction results of multiple transactions in each merged group to obtain the deduction results of each merged group. The second merging unit is used to obtain the merged billing results of multiple transactions based on the deduction results of each merged group. The reconciliation unit is used to determine the difference between the deduction results and the billing results of each merged group.

[0037] In a third aspect, a computing device is provided, which includes a processor and a memory, wherein the memory is used to store instructions and the processor is used to execute instructions, so that the computing device implements the method described in the first aspect.

[0038] In a fourth aspect, a computer-readable storage medium is provided, in which instructions are stored. When the instructions are executed by a computing device or a computing device cluster, the method described in the first aspect is implemented.

[0039] In a fifth aspect, a computing device cluster is provided, which includes at least one computing device, each of the at least one computing device includes a processor and a memory, and the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster implements the method described in the first aspect.

[0040] In a sixth aspect, a computer program product comprising instructions is provided, wherein the computer program product includes instructions that can be run on a computing device or stored in software or program products in any available medium, and when the computer program product is run on a computing device or a computing device cluster, the computing device or computing device cluster executes the method described in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] FIG1 is an architecture diagram of a reconciliation system provided by this application;

[0042] FIG2 is a schematic diagram of the steps of a reconciliation method provided by the present application;

[0043] FIG3 is an example diagram of a configuration interface provided by this application;

[0044] FIG4 is an example diagram of a bitmap provided by the present application;

[0045] FIG5 is an example diagram of another bitmap provided by the present application;

[0046] FIG6 is an example diagram of steps for reading a billing bitmap containing combined billing attributes based on a mask provided by the present application;

[0047] FIG7 is an example diagram of a channel cost reconciliation interface provided by this application;

[0048] FIG8 is a schematic diagram of the structure of a computing device provided by the present application. DETAILED DESCRIPTION

[0049] First, some of the terms involved in this application are explained.

[0050] Payment channels: refers to the channels on the third-party payment platform that support platform users to complete payment operations, such as credit cards, debit cards, e-wallets, mobile payments, virtual currencies, etc. These payment channels not only help platform users complete the payment of transaction amounts, but also support the flow, reconciliation and clearing of funds between the platform and banks.

[0051] Clearing: Calculate the amount that each party needs to pay and receive during the transaction process, and determine the transaction details of each party, such as accounts payable and accounts receivable.

[0052] Billing: The general meaning of billing is to calculate the fee. In the embodiment of this application, the calculated fee refers to the handling fee charged by the payment channel company for each transaction through the payment channel.

[0053] Billing rules: The fees charged by the payment channel company are determined according to certain billing rules. These billing rules are the billing rules agreed upon with the payment channel company, such as proportional, fixed amount, single transaction tiered, cumulative tiered, etc.

[0054] Channel cost: The cost incurred to complete the payment action using channel costs. This cost includes at least channel handling fees, and may also include some other fees, such as promotion fees, brand fees, etc. Channel cost can be understood as the additional fees that the third-party payment platform needs to pay in the process of completing a transaction.

[0055] Reconciliation: In the embodiment of the present application, reconciliation refers to the third-party payment platform comparing the channel costs obtained by billing with the channel costs charged by the bank.

[0056] Write-off: In finance, write-off usually refers to confirming the accuracy of accounts or transactions. For example, when a debt is paid off, the finance department can write off the financial records corresponding to the debt.

[0057] Secondly, the application scenarios involved in this application are explained.

[0058] A third-party payment platform is a company or institution that provides a settlement channel between buyers and sellers. Under this model, buyers select and purchase goods and pay the third-party payment platform. The third-party payment platform then notifies the seller of the goods for shipment. Once the buyer confirms receipt, the third-party payment platform transfers the payment to the seller's account, completing the transaction. Third-party payment platforms integrate multiple payment channels, such as online banking, mobile QR codes, and bank cards, to accommodate the diverse payment habits of both buyers and sellers.

[0059] For every transaction made by a platform user through a payment channel, the third-party payment platform must pay a fee to the payment channel company. Therefore, the third-party payment platform must maintain a separate channel cost bill to record the channel fee payable for each transaction. Banks also maintain a channel deduction bill to record the actual channel fee deducted for each transaction. During channel cost reconciliation, the third-party payment platform must compare the channel cost bill with the channel deduction bill issued by the bank to ensure consistency between the payable and actual fees paid. If there is a discrepancy, staff must investigate the cause and adjust the channel cost bill.

[0060] However, due to various normal reasons, it is very easy for the payable fees calculated by the third-party payment platform to be inconsistent with the actual paid fees. For example, the bank and the third-party payment platform may process transactions at different time points. If one party calculates the fees and the other party has not completed the corresponding processing, it may lead to inconsistencies between the payable fees and the actual paid fees. For example, when there are a large number of transactions, the transaction sequence recorded by the third-party payment platform and the bank is likely to be inconsistent, which may also lead to different fee calculation results. For example, the bank and the third party may use different fee calculation rules, which may also lead to different fee calculation results. For example, the bank temporarily raises the fee rate, or the bank temporarily discounts the fee rate. For example, in a complex network environment involving multiple systems and platforms, transaction information may be difficult to synchronize in a timely manner due to communication delays and other problems, resulting in inconsistent fee calculations. A third-party payment platform may have tens of thousands of transactions a day, which often leads to inconsistencies between the payable fees and the actual fees paid. This requires a large number of employees to adjust the channel cost bills. Not only is the labor cost high and the adjustment efficiency low, but the accuracy of the adjustment also depends on the professionalism of the employees, affecting the accuracy and timeliness of the third-party payment platform's general ledger.

[0061] In order to solve the problems of high labor costs and low adjustment efficiency in the reconciliation of the above-mentioned channel fees, which affect the accuracy and timeliness of the financial general ledger, the present application provides a reconciliation solution. In this solution, the reconciliation system can obtain transaction data of multiple transactions from the payment channel system, determine the billing results of the payment channel costs of each transaction based on the billing model, and then obtain the deduction results of the payment channel costs of each transaction from the bank system. The billing results of multiple transactions are merged to obtain a consolidated billing result, and the deduction results of multiple transactions are merged to obtain a consolidated deduction result. The difference between the consolidated billing result and the consolidated deduction result is determined. When the difference exceeds the warning threshold, an early warning message is sent to the management user to instruct the user to update the billing model, so that consolidated reconciliation can be performed when reconciling channel costs, and there is no need to reconcile one by one, thereby improving reconciliation efficiency. At the same time, the management user can update the billing model according to the early warning information, and there is no need to adjust the accounts one by one, thereby improving reconciliation efficiency, reducing labor costs, and improving user experience.

[0062] FIG1 is an architecture diagram of a reconciliation system provided by this application. As shown in FIG1 , the architecture may include a client 100, a payment channel system 200, a bank system 300, and a reconciliation system 400. A communication connection exists between the client 100, the payment channel system 200, the bank system 300, and the reconciliation system 400. This communication connection may be a wired connection or a wireless connection, which is not specifically limited in this application. The number of payment channel systems 200, bank systems 300, and clients 100 that establish communication connections with the reconciliation system 400 may be one or more, which is not specifically limited in this application.

[0063] The client 100 is used to implement human-computer interaction and can be deployed on terminal devices, including personal computers, smart phones, wearable devices, handheld processing devices, tablet computers, mobile notebooks, augmented reality (AR) devices, virtual reality (VR) devices, integrated handheld devices, wearable devices, vehicle-mounted devices, smart conferencing devices, smart advertising devices, smart home appliances, etc. Smart home appliances can be sweeping robots, mopping robots, etc., which are not specifically limited here.

[0064] The holder of client 100 is the administrative user who maintains reconciliation system 400 and is an employee of the third-party payment platform, typically a financial or information technology (IT) personnel. This application does not impose any specific limitations. It should be understood that platform users are consumers who purchase goods using the third-party payment platform. The reconciliation system provided in this application is primarily intended for administrative users and requires completing channel cost reconciliation based on transaction data triggered by platform users.

[0065] In a specific implementation, the client 100 can be software or an application running on a terminal device or a computing device controlled by the management user, such as a personal computer (PC) client, a browser-based World Wide Web (web) client, an application (APP) client running on a mobile terminal, or a console of a cloud platform, and this application does not make any specific limitations.

[0066] Optionally, the client 100 can be a client specifically used to implement the reconciliation function, such as reconciliation software, reconciliation assistant and other clients. Alternatively, the client 100 can be a comprehensive client that includes a reconciliation function or module, such as financial accounting software, which provides a reconciliation function so that management users can compare accounts, transactions and financial records. For example, an enterprise resource planning system includes modules such as financial management, supply chain management, and human resources management, and its financial management module can be used to perform reconciliation, bookkeeping, report generation and other functions. For example, a third-party payment platform usually includes order management and reconciliation functions to ensure the consistency of orders, inventory and payments. The above examples are for illustration purposes only, and this application does not limit the specific form of the client.

[0067] Optionally, the client 100 may also be a client of a cloud platform, such as a console of the cloud platform, which may be a web-based console or an application programming interface (API)-based console, which is not specifically limited in this application. The console may provide users with a reconciliation cloud service, and the management user may obtain access to the reconciliation system 400 provided in this application by purchasing the cloud service.

[0068] The payment channel system 200, banking system 300, and reconciliation system 400 can be deployed on a computing device or computing device cluster. Computing devices include bare metal servers (BMSs), virtual machines (VMs), containers, or edge computing devices. A BMS refers to a general-purpose physical server, such as an ARM server or an X86 server. A VM is a complete computer system with complete hardware system functionality, running in a completely isolated environment, simulated by software. Any tasks that can be performed on a physical computer can also be performed on a VM. When creating a VM on a computing device, a portion of the physical machine's hard disk and memory capacity is used as the VM's hard disk and memory capacity. Each VM has its own independent basic input / output system (BIOS), hard disk, and operating system, allowing it to be operated just like a physical machine. A container is a portable software unit that combines an application and all its dependencies into a single software package. This package is not restricted by the underlying host operating system, eliminating the need to build a complex environment and simplifying the application development and deployment process. Edge computing devices are devices that are closer to data sources or user terminals and feature low latency and high bandwidth, such as smart routers and edge servers. The computing device cluster may include multiple computing devices as described above, such as a data center, which is not specifically limited in this application.

[0069] Among them, the payment channel system 200 is a system maintained by the payment channel company, which is mainly used to receive payment instructions sent by the mall system of the third-party platform, then generate transaction data according to the payment instructions, and then send the transaction data to the reconciliation system 400 and the bank system 300 of the third-party platform. The explanation of the payment channel can refer to the description of the aforementioned terminology part, which will not be repeated here.

[0070] Bank system 300 is a bank-maintained system primarily used to receive transaction data sent from the payment channel company's payment channel system 200, deduct channel fees based on the transaction data, generate channel deduction bills, and send the channel deduction bills to the third-party platform's reconciliation system 400 to complete channel cost reconciliation. Bank system 300 can be a system maintained by a single bank, or a system jointly maintained by multiple banks, such as UnionPay, NetsUnion, or a Bank-NetsUnion system, and this application does not impose any specific limitations.

[0071] The reconciliation system 400 is a system maintained by the third-party payment platform. It is mainly used to receive transaction data sent by the payment channel system 200 and the channel deduction bill sent by the bank system 300. It then completes the reconciliation of channel costs based on the transaction data and the channel deduction bill. It should be noted that the reconciliation system 400 shown in Figure 1 is a subsystem in the third-party payment platform. The third-party payment platform also includes a mall system for completing purchase operations of platform users, generating transaction instructions, and then sending the transaction instructions to the payment channel system 200, so that the payment channel system generates transaction data based on the payment instructions. Since the invention of this application focuses on reconciliation, the third-party payment platform and the mall system in the third-party payment platform are not drawn.

[0072] Optionally, the client 100 and the reconciliation system 400 can be deployed on the same computing device, for example, both the client 100 and the reconciliation system 400 are deployed on a server maintained by the company's financial department; or the client 100 is deployed on a terminal device, and the reconciliation system 400 is deployed on a computing device, for example, the client 100 is deployed on a personal mobile phone of a financial employee, and the reconciliation system 400 is deployed on the company's server; or the client 100 and the reconciliation system 400 are deployed on different computing devices in the same computing device cluster, for example, the client 100 can be deployed on the company's office computer, and the reconciliation system 400 can be deployed on the company's server, and the office computer and the server belong to the same computing device cluster and use the same company internal network; or the client 100 and the reconciliation system 400 are deployed in different computing device clusters, for example, the client 100 is deployed on the company's office computer, and the reconciliation system 400 is deployed on a cloud server in a public cloud. The above examples are for illustration only and are not specifically limited in this application.

[0073] Optionally, the payment channel system 200 and the bank system 300 can be deployed on the same computing device or the same computing device cluster, in which case the payment channel system is the bank's payment channel system. It should be understood that banks can also provide payment channels for third-party payment platforms. For example, when selecting payment channels such as ICBC or ABC for payment, the payment channel system 200 and the bank system 300 can be deployed on the same computing device or the same computing device cluster. The payment channel system 200 and the bank system 300 can also be deployed on different computing device clusters, in which case the payment channel system 200 can be a non-bank payment channel, which will not be explained here.

[0074] Optionally, the reconciliation system 400 can be deployed on the same computing device or the same computing device cluster as the payment channel system 200. In this case, the third-party payment platform has its own payment channel. In other words, the reconciliation system and the payment channel system belong to the same third-party payment platform. It should be understood that some third-party payment platforms have their own payment channels. For example, if the third-party payment platform is Huawei Mall and the payment channel is Huawei Wallet, the payment channel system is a subsystem of the third-party payment platform. Therefore, the payment channel system 200 and the reconciliation system 400 can be deployed on the same computing device cluster or the same computing device. The above examples are for illustration only and are not specifically limited in this application.

[0075] Furthermore, the reconciliation system 400 in FIG1 can be further divided into one or more unit modules. For example, as shown in FIG1 , the reconciliation system 400 includes a configuration unit 410, a single billing unit 420, a first merging unit 430, a receiving unit 440, a second merging unit 450, a reconciliation unit 460, an analysis unit 470, and a storage device 480. It should be understood that FIG1 is an exemplary division method, and the reconciliation system 400 may also include more or fewer units, which is not specifically limited in this application.

[0076] It should be noted that the structure shown in Figure 1 can be an implementation method in which the reconciliation system 400 is deployed on a single computing device. When the reconciliation system 400 is deployed on a computing device cluster consisting of multiple computing devices, different computing devices in the computing device cluster can respectively store instructions for implementing the configuration unit 410, the single billing unit 420, the first merging unit 430, the receiving unit 440, the second merging unit 450, the reconciliation unit 460, the analysis unit 470 and the storage device 480. For example, the computing device A in the computing device cluster stores instructions for implementing the configuration unit 410, the single billing unit 420, the first merging unit 430, the receiving unit 440, and the second merging unit 450, and the computing device B stores instructions for implementing the reconciliation unit 460, the analysis unit 470 and the storage device 480. The above examples are for illustration only and are not specifically limited in this application. Of course, different computing devices may also store the same instructions. For example, computing device A and computing device C both store instructions for the configuration unit 410, the single billing unit 420, the first merging unit 430, the receiving unit 440, and the second merging unit 450, which are used to combine and implement the functions of the configuration unit 410, the single billing unit 420, the first merging unit 430, the receiving unit 440, and the second merging unit 450. This application does not make specific limitations.

[0077] The following is an explanation based on the functions of each unit module in the reconciliation system 400.

[0078] The configuration unit 410 is used to generate a billing model and store it in the storage device 480 .

[0079] Optionally, the billing model may include billing elements and billing rules, wherein each billing rule corresponds to a set of billing elements. Based on the billing elements contained in each transaction data, the billing rules that need to be used for the transaction data can be determined.

[0080] In specific implementation, the billing elements may include some necessary information for determining the billing rules to be used for transaction data. Such necessary information may be information related to the payment channel in the transaction data, such as the payment channel name, payment channel product name, institution code, channel type, channel subtype, bank name, etc., wherein the payment channel name refers to the name of the payment channel, such as Xbao, X Wallet, etc.; the payment channel product name refers to the specific product name under the payment channel, such as Xbao including balance payment, credit payment, installment payment, etc.; the institution code is a unique identifier used to distinguish banks, financial institutions, payment channel companies, etc., which helps to ensure Accurately identify these banks, financial institutions and payment channel companies in different systems and transactions; channel type refers to the transaction method, such as physical channels (physical stores), online channels (e-shopping, mobile applications, etc.), agent channels, etc.; channel subtype refers to a more specific classification of channel types, such as channel subtypes of physical channels may include specialty stores, vending machines, exhibitions, etc., channel subtypes of online channels may include e-commerce platforms, social media, mobile applications, official websites, etc., and channel subtypes of agent channels may include dealers, agents, partner programs, etc.; bank name may be the name of the bank that completes the channel fee deduction. The above examples are for illustration purposes only, and billing elements may also include more content, such as bank card type, industry, etc., which are not specifically embodied in this application.

[0081] It should be understood that the more detailed the billing elements, the more accurate the corresponding billing rules, but the more complex the corresponding relationships. Therefore, the content of the billing elements and the corresponding relationships can be determined based on actual business needs and the processing capabilities of the system. The above provides a few possible billing elements, which are not specifically limited in this application. At the same time, if the user needs to modify or add a billing rule, it will not affect other billing rules, making the reconciliation system 400 more flexible and scalable.

[0082] In a specific implementation, the billing rules may include the billing method of the channel handling fee. For example, the billing rules may include the billing type, the effective time of the fee, and the billing mode. The billing type is used to distinguish the billing method, the effective time of the fee is used to define the effective time range of the billing, and the billing mode is used to describe the billing details under the billing type. The billing type, the effective time of the fee, and the billing mode can constitute a complete billing rule. Different billing rules correspond to different billing types, effective times, or billing modes. For example, billing rules 1 and billing rules 2 have the same billing type and billing mode, but different effective times. For example, billing rules 3 and billing rules 4 have different billing types, but the same billing effective time and billing mode.

[0083] The following explains the billing type, fee effective time, and billing mode in the billing rules.

[0084] Billing types include single-transaction billing, single-transaction gradient billing, and cumulative gradient billing. The specific billing type can be determined according to the actual business scenario and is not specifically limited in this application. Among them, single-transaction billing means that each transaction is billed according to a certain billing model, and single-transaction gradient billing means charging fees in stages according to different parts of the transaction amount. That is, the transaction amount is divided into several gradients, and each gradient is billed according to a different billing model. For example, the first 100 yuan is charged at 1%, 101 to 200 yuan is charged at 0.8%, and more than 200 yuan is charged at 0.5%. Cumulative gradient billing means charging different stages of fees according to the cumulative transaction amount within a certain time range. For example, within a month, a 1% handling fee is charged for transactions totaling 1,000 yuan, a 0.8% handling fee is charged for transactions between 2,000 and 5,000 yuan, and a 0.5% handling fee is charged for transactions above 5,000 yuan. It should be understood that billing types can also include more content and are not specifically limited in this application.

[0085] The fee effective time may include immediate, daily, or monthly, and the specific time can be determined based on the actual business scenario and is not specifically limited in this application. Immediate means that the fee is charged immediately after each transaction occurs, daily means that the fee is charged uniformly on a daily basis, and monthly means that the fee is charged uniformly on a monthly basis. The above examples are for illustrative purposes only and are not specifically limited in this application.

[0086] The billing model may include fixed fees, percentage fees, mixed billing, etc. The specific billing type can be determined according to the actual business scenario, and this application does not make specific restrictions. A fixed fee refers to a fixed amount charged for each transaction, a percentage fee refers to a fee charged as a percentage of the transaction amount, and a mixed billing refers to charging partly according to a fixed fee and partly according to a percentage fee. The billing model can also include more detailed content. For example, a fixed fee can be further divided into brand fees, network service fees, payable business participation prices, etc. The specific details can be determined according to the actual business scenario, and examples are not given here.

[0087] It should be noted that the optional billing modes under different billing types are also different. For example, the billing mode under single billing does not include ladder information, while the billing modes under billing types such as single gradient billing and cumulative gradient billing need to additionally include ladder information, such as ladder sequence number, ladder start, ladder end, etc. For another example, fixed fees may include minimum guarantee fees, maximum guarantee fees, etc. The minimum guarantee fee refers to the payment channel company setting a minimum threshold and a minimum guarantee amount. If the total amount of fees for this month does not exceed the minimum threshold, then the fee will be charged according to the minimum guarantee amount. Similarly, the maximum guarantee fee refers to setting a maximum threshold and a maximum limit. If the maximum threshold is exceeded, a fixed fee will be charged according to the maximum limit. The above examples are for illustration only and are not specifically limited in this application.

[0088] It should be understood that the billing rules, through the free combination of the above-mentioned billing type, billing mode, and fee effective time, make the configuration of billing rules more flexible and improve the user experience. Of course, billing rules can also be implemented through the combination of more elements, such as billing accumulation period, refund mode, etc., which are not illustrated here one by one.

[0089] Optionally, the billing model not only includes the above-mentioned billing elements and billing rules, but also may include more content, such as settlement mode, fee collection method, fee collection cycle, etc. The content of the billing model can be determined according to the actual business scenario, and examples are not given here one by one.

[0090] Optionally, the reconciliation system 400 can pre-establish correspondences between multiple sets of billing elements and billing rules, from which the management user can select billing elements and billing rules to complete the configuration of the billing model. Specifically, the management user can initiate a configuration request using a graphical user interface (GUI). The client 100 can display the selectable billing elements and billing rules to the management user. The reconciliation system 400 can then generate a billing model based on the billing elements and billing rules selected by the management user and store it in the storage device 480. This allows subsequent billing of transaction data to be completed according to the billing model.

[0091] Optionally, the reconciliation system 400 may also receive billing elements and billing rules uploaded by the management user to generate a billing model. Specifically, the management user may configure the billing model by modifying a configuration file, importing a model through a GUI, etc., which is not specifically limited in this application.

[0092] It should be understood that this application pre-configures billing elements and billing rules, and then manages users to configure the billing model by choice, making the model configuration simpler, faster, and more flexible, thereby improving the user experience.

[0093] In the specific implementation, the billing model is a calculation model. The billing results can be obtained by inputting transaction data into the billing model. The billing model can match the transaction data with the billing elements in the billing model, determine the billing rules corresponding to the transaction data, and then use the billing rules to complete the billing. The billing model may include the types of fees that need to be calculated and the corresponding fee calculation methods. The types of fees include channel fees, clearing fees, settlement fees, network fees, technical support fees, risk management fees, compliance and regulatory fees, promotion and duration fees, brand fees, etc. The fee calculation method can be determined according to the specific business scenario, and this application does not make specific limitations.

[0094] The single transaction billing unit 420 is used to obtain transaction data and obtain a billing result for each transaction in the transaction data based on a billing model.

[0095] Optionally, after a mall user places an order through the mall system of a third-party payment platform, the mall system may generate a payment instruction and then send the payment instruction to the payment channel system 200. The payment channel system 200 generates transaction data based on the payment instruction and then sends the transaction data to the single billing unit 420 of the reconciliation system 400 of the third-party payment platform. At the same time, the transaction data is sent to the bank system 300 to complete the deduction of the channel handling fee. After the bank system 300 generates the channel deduction bill, it feeds it back to the reconciliation system 400, so that the reconciliation system 400 can complete the channel cost reconciliation based on the transaction data and the channel deduction bill.

[0096] In a specific implementation, a payment instruction is a generated payment instruction that may include information such as the payment amount, payment method, payee information, payment initiator information, transaction description, transaction serial number, and payment timestamp. Transaction data is generated by the payment channel system 200 based on the payment instruction. The transaction data may include transaction data for multiple transactions, each of which includes transaction amount, transaction status, transaction time, payment serial number, payment channel information, payment channel serial number, merchant information, and mall user information. The above examples are for illustrative purposes only. Payment instructions and transaction data may include more information, which is not fully detailed here.

[0097] Optionally, after obtaining the transaction data, the single billing unit 420 can determine the transaction attributes of each transaction based on the transaction data of each transaction. The transaction attributes are used to describe the relevant characteristics of the transaction data of the transaction. For example, the transaction attributes may include transaction time, payment channel code, bank code, transaction amount, transaction status, transaction type, currency type, merchant code, settlement mode, etc., wherein the transaction time refers to the specific time of the transaction; the payment channel code refers to the code of the payment channel, which is usually a unique code; the bank code is the code of the bank; the transaction amount refers to the amount paid by the mall user through the payment channel; the transaction status refers to the processing status of the transaction, which can be pending, completed, failed, etc.; the transaction type refers to the transaction status of the transaction. Transaction type, which can be shopping, transfer, refund, etc.; currency type refers to the currency type of the transaction, such as RMB, USD, JPY, etc.; merchant code refers to the payee of the transaction. Similarly, transaction attributes can also include user code, which is the payee of the transaction; settlement mode refers to the settlement type of the transaction in the channel cost reconciliation process, including no settlement, full settlement and netting settlement, etc. No settlement means that there is no specific currency exchange in the channel cost reconciliation, for example, one party provides a certain service to the other party; full settlement means that the channel cost is calculated based on all payables, and the amount paid is full settlement; netting settlement means that the settlement amount is adjusted based on the payables, and there may be discounts, discounts, refunds, etc. It should be understood that the examples of the above transaction attributes are for illustration only and are not specifically limited in this application.

[0098] In a specific implementation, the single-transaction billing unit 420 may merge multiple transaction data items with multiple identical transaction attributes into a batch of transaction data and write the data into a transaction attribute table. The transaction attribute table includes multiple fields, each field representing a transaction attribute. Each row of data in the transaction attribute table is used to indicate a batch of transaction data for multiple transactions with the same transaction attributes. It should be noted that a transaction can have multiple transaction attributes. Therefore, a batch of multiple transactions with the same transaction attributes can have all or some of the same transaction attributes. For example, if a transaction has 10 transaction attributes, then multiple transactions with 9 identical transaction attributes can be written as a batch into a row of data in the transaction attribute table. Alternatively, multiple transactions with 10 identical transaction attributes can be written as a batch into a row of data in the transaction attribute table. This application does not impose any specific limitations on this.

[0099] For example, Table 1 below is an example of a transaction attribute table for transaction data. As shown in Table 1, a row of data represents multiple transaction attributes for a batch of transaction data. For example, a row of transaction data corresponding to sequence 1 includes the following transaction attributes: transaction date: August 11, 2023, payment channel code: 0001, bank code: 0102, transaction amount: 1 million yuan, transaction type: shopping, and transaction status: completed. Similarly, the transaction attributes for multiple groups of transaction data corresponding to sequences 2, 3, and 4 can be determined. Table 1 is an example only; the transaction attribute table may include more or fewer fields, and this application does not impose specific limitations.

[0100] Table 1 An example of a transaction attribute table for transaction data

[0101] It is understandable that through the transaction attribute table, multiple transactions with the same transaction attributes can be merged, so that a row of data in the transaction attribute table can be billed using the same billing rule, thereby improving billing efficiency.

[0102] Optionally, since the volume of transaction data is often very large, to ensure efficient data querying, an index can be assigned to each batch of transaction data. Specifically, an additional index field can be maintained in the transaction attribute table. This index can be the hash value of multiple fields. For example, in the example shown in Table 1, the hash value of the transaction date, payment channel code, and bank code of sequence 1 can be used as the index of sequence 1. Similarly, the hash value of the transaction date, payment channel code, and bank code of sequence 2 can be used as the index of sequence 2. In this way, each row of data can correspond to an index, and each row of transaction data can be queried using the index, improving data query efficiency.

[0103] Furthermore, if multiple rows of transaction data with the same hash value exist, the rows corresponding to the same hash value can be concatenated into a linked list, with each row corresponding to a node in the linked list. Specifically, an additional field for identifying the linked list nodes can be maintained in the transaction attribute table, such as a linked list node sequence or a preceding node sequence. This allows multiple rows of transaction data with the same hash value to be concatenated into a linked list, with each row corresponding to a different linked list node. This allows querying data by first reading the entire linked list corresponding to the hash value, then traversing the transaction data corresponding to each linked list node in sequence according to the node order described by the linked list node field, until finding transaction data that meets the query criteria. This avoids index invalidation due to hash conflicts. The linked list nodes can be arranged in the order in which they were added.

[0104] For example, Table 2 is an example of a transaction attribute table for transaction data. The difference between Table 1 and Table 2 is that Table 2 additionally adds a hash value field and a preceding node field, wherein the hash value field is an index, and the corresponding transaction data can be read according to the hash value when querying data. If the hash values ​​of multiple rows of data are the same, then the order of multiple linked list nodes in the linked list corresponding to the hash value can be determined according to the preceding node field. For example, in a batch of transaction data of sequence 4, the preceding node is 1, that is, in the linked list with a hash value of hash1, the first linked list node is sequence 1, and the second linked list node is sequence 4. If the hash value corresponding to sequence 5 is also hash1, then its preceding node is sequence 4. It should be understood that Table 2 is used for illustration, and the preceding node field can also be directly replaced by the linked list sequence field, which is directly used to determine the serial number of the row of data in the linked list. Then the linked list sequence of sequence 1 is 1, and the linked list sequence of sequence 4 is 2. It should be understood that the above example is used for illustration and this application does not make specific limitations.

[0105] Table 2 Another example of transaction attribute table for transaction data

[0106] It should be understood that the above solution solves hash conflicts by means of a linked list. In specific implementations, hash conflicts can also be solved by other means, such as randomly taking a new hash value. This application does not limit the specific method of solving hash conflicts.

[0107] Optionally, the billing results may include a detailed breakdown of the channel costs for each transaction, where the channel costs refer to the additional costs that the third-party payment platform needs to pay during the transaction. In specific implementations, the channel costs may include channel fees that need to be paid to the payment channel company, and may also include other fees, such as clearing fees, settlement fees, network fees, technical support fees, risk management fees, compliance and regulatory fees, promotion and duration fees, brand fees, etc. The specific fee items included in the channel costs can be determined based on the actual business scenario, and this application does not make specific restrictions. Among them, the channel cost details may include the name and amount of each fee item included in the channel cost, and may also include the calculation process of each fee, which is not specifically limited in this application.

[0108] Optionally, the billing results may include the clearing results of each transaction, where clearing refers to calculating the amount that each participant needs to pay and receive during the transaction, and determining the payables and receivables of each participant. Participants may be initiators, recipients, banks, payment channel companies, third-party payment platforms, brand companies, payment gateways, etc., and the payables and receivables of each participant can also be subdivided. For example, the payables of the payment channel company include channel fees and brand fees, and the receivables include the payment paid by mall users and the platform fees paid by merchants. Simply put, the channel cost details calculate the details of some channel costs that the third-party payment platform needs to pay, and the clearing results are the amounts that multiple participants need to pay and receive. There is a certain degree of overlap between the clearing results and the channel cost details calculation, but the clearing results contain more detailed and richer content.

[0109] It should be understood that the billing results may also include more content, which can be determined according to the actual application scenario and is not specifically limited in this application.

[0110] Optionally, single-transaction billing unit 420 can complete the billing result for each transaction based on the billing model in storage device 480. Specifically, single-transaction billing unit 420 matches the transaction attributes of each transaction data with the billing elements in the billing model, determines the billing rule corresponding to each transaction, and then uses the billing rule to complete the billing of the transaction, thereby obtaining the billing result for the transaction. As previously mentioned, each row in the transaction attribute table indicates a batch of transaction data with the same transaction attributes. Therefore, each row of transaction data can be billed using the same billing rule, thereby improving billing efficiency.

[0111] Optionally, the single billing unit 420 can generate a bitmap corresponding to the billing result of each transaction after obtaining the billing result of each transaction. The bitmap includes multiple bits, each bit is used to describe a billing attribute in the billing result, and the value of the bit is used to indicate whether the billing attribute exists. For example, the value of the bit can be a binary value, such as 0 represents that the billing attribute does not exist, and 1 represents that the billing attribute exists. It should be understood that the bits in the bitmap are represented by binary values, so that when subsequent data is read, the billing results that meet specific billing attributes can be quickly screened out through masking, bit operations, etc., making the retrieval method faster and improving data query efficiency.

[0112] Specifically, the billing attributes are used to describe the relevant features in the billing results. The billing attributes include the transaction attributes of the transaction data corresponding to the billing results, such as transaction date, payment channel code, bank code, transaction amount, transaction status, transaction type, currency type, merchant code, settlement mode, etc.; the billing attributes also include attributes related to the channel cost details in the billing results, such as channel handling fees, clearing fees, settlement fees, network fees, technical support fees, risk management fees, compliance and regulatory fees, promotion and duration fees, brand fees, etc.; it may also include attributes related to the clearing results, such as the names of the participants, the names of the fees payable by the participants, etc., which are not specifically limited in this application.

[0113] It should be understood that the billing attribute represented by each bit in the bitmap can be determined according to the actual business scenario. The billing attributes that may be filtered during reconciliation can be used as bits in the bitmap. For example, if the user needs to filter the billing results of all transactions whose payment channel is a certain bank, then the bank number can be used as a bit. For example, if the user needs to filter the billing results of all transaction data on a certain day, then the transaction date can be used as a bit. Therefore, the billing attribute represented by each bit in the bitmap can be flexibly set according to user needs, and can also make the subsequent reconciliation reading of the billing results more efficient, thereby improving the reconciliation efficiency.

[0114] Furthermore, the single-billment unit 420 can establish a detailed table based on the bitmap, wherein a mapping relationship exists between the detailed table and the bitmap, with one bitmap corresponding to one detailed table. The bitmap is used to record the billing attributes included in the billing result, and the detailed table is used to record the values ​​corresponding to the billing attributes. For example, if the bitmap records that the billing result includes a network service fee, then the detailed table corresponding to the bitmap records that the amount of the network service fee is 2 yuan. It should be noted that the detailed table can also be stored in the storage device 480, and the mapping relationship between the detailed table and the bitmap is also stored in the storage device 480.

[0115] For example, the bitmap includes 5 bits, the first bit represents the network service, the second bit represents the brand fee, the third bit represents the bank fee, the fourth bit represents the business participation price (some specific businesses require participants to pay additional fees, such as entrance fees, membership fees, etc.), and the fifth bit represents the promotion fee. If the billing result includes a total channel cost of 5 yuan, including 1 yuan for network service fee, 2 yuan for brand fee, and 2 yuan for bank fee, then the bitmap of the billing result can be: (1,1,1,0,0), and the detailed table corresponding to the bitmap includes a network service fee of 1 yuan, a brand fee of 2 yuan, and a bank fee of 2 yuan. It should be understood that the above examples are for illustration only and are not specifically limited in this application.

[0116] It should be understood that the billing results of each transaction are recorded through a bitmap, including the billing attributes contained in the billing results of each transaction, and then the specific value of each billing attribute is recorded through a detailed table. Under this implementation method, the bitmap can not only effectively save storage space, but also quickly filter out billing results that meet specific billing attributes through masks, bit operations, etc. The retrieval method is faster, which improves data query efficiency. At the same time, the bitmap is also easy to expand. When adding new billing attributes, the new billing attributes can be supported by expanding the bitmap and detailed table without modifying the entire data structure, making the billing results easier to maintain.

[0117] The first merging unit 430 is configured to merge multiple charging results to obtain a merged accounting result.

[0118] Optionally, the first merging unit 430 may merge multiple billing results containing the same combined billing attribute to obtain a combined accounting result, wherein the combined billing attribute may be set by the management user or set by default by the reconciliation system 400. For example, if the combined billing attribute is a certain time point or time period, the first merging unit 430 merges all billing results within that time point or time period to obtain a combined accounting result. Alternatively, if the combined billing attribute is a certain bank and a certain time period, the first merging unit 430 merges all billing results involving the bank within the time period to obtain a combined accounting result. This application does not specifically limit the combined billing attribute.

[0119] Optionally, the first merging unit 430 can obtain multiple billing results from the bitmap based on the combined billing attributes and then merge them. Specifically, a mask can be generated based on the combined billing attributes, and the mask can be used to perform a bitwise AND operation on the bitmap. If the result of the bit after the operation is non-zero, it means that the billing result contains the billing attribute represented by the bit. If the result of the bit after the operation is zero, it means that the billing result contains the billing attribute represented by the bit. Based on the result of the mask operation, a bitmap that meets the conditions can be obtained, and then based on the detailed table corresponding to the bitmap, multiple billing results that meet the combined billing attributes can be obtained, thereby obtaining a combined accounting result.

[0120] For example, assuming that the bitmap is defined as (network service fee, brand fee, bank handling fee, promotion fee), bitmap 1 is 0100, indicating that billing result 1 includes brand fee, bitmap 2 is 1101, indicating that billing result 2 includes network service fee, brand fee and promotion fee, and the combined billing attribute is promotion fee. The mask 0001 is used to perform a bitwise AND operation with the bitmap. The operation result of bitmap 1 is 0000, and the operation result of bitmap 2 is 0001. Therefore, the billing result corresponding to bitmap 2 includes promotion fee and can be read out. It should be understood that by storing and reading billing results in the form of bitmaps and masks, a large number of billing results that meet the conditions can be quickly read out for combined accounting, thereby improving the efficiency of combined accounting.

[0121] It should be noted that if the bit corresponding to the consolidated billing attribute does not exist in the bitmap, multiple transaction data corresponding to the consolidated billing attribute can be obtained from the transaction attribute table, and then the bitmap corresponding to the above multiple transaction data can be obtained to complete the consolidated accounting.

[0122] In a specific implementation, when merging multiple billing results, the first merging unit 430 may first merge the channel costs of multiple transactions to obtain a merged billing amount, and then generate a merged accounting result based on the merged billing amount. The merged accounting result includes the merged billing amount and other information.

[0123] The consolidated billing amount includes the total amount of channel costs for multiple transactions and the total amount of multiple categories. A category can be a certain type of handling fees in multiple transactions, such as the total amount of clearing fees, the total amount of settlement fees, the total amount of network fees, the total amount of technical support fees, the total amount of risk management fees, the total amount of compliance and regulatory fees, the total amount of promotion and duration fees, the total amount of brand fees, etc. A category can also be the consolidated handling fees screened out by a certain billing attribute in multiple transactions, such as calculating the total amount of channel costs that need to be paid to Bank A in multiple transactions, such as calculating the total amount of brand fees that need to be paid at time T1-T2 in multiple transactions, etc., such as calculating the total amount of channel costs in multiple transactions with a transaction status of completed. The specific amount can be determined according to actual business needs, and this application does not make specific limitations.

[0124] Other information may include transaction information, such as the transaction time, transaction number, transaction amount, payment channel, transaction status, etc. of each transaction; the consolidated accounting results may also include billing results, such as the billing results, billing rules, billing time, etc. of each transaction; the consolidated accounting results may also include consolidated information, such as the consolidated date, the consolidated number of transactions, the consolidated total amount, etc.; the consolidated accounting results may also include channel cost information, such as the channel name, channel fees, the consolidated total amount of channel costs, etc.; the consolidated accounting results may also include total information, such as the total number of transactions, the total transaction amount, the total billing amount, the total channel cost, etc. The above examples are for illustration only. The consolidated accounting results may also include more content, which can be determined based on the business needs during the actual channel cost reconciliation. This application does not make any specific limitations.

[0125] It should be noted that the reconciliation system 400 may be pre-configured with template information for the consolidated accounting results. This template information includes some necessary fields in the consolidated accounting results, such as the transaction information, billing results, consolidated information, channel cost information, and total information described above. This template information may be user-configured or pre-recommended by the reconciliation system 400, and this application does not impose any specific limitations. In this way, the first consolidation unit 430 can obtain various consolidated amounts based on the fields required to be filled in the template information, fill in the fields, and generate the consolidated accounting results.

[0126] Furthermore, the first merging unit 430 can obtain multiple merged groups based on different merged billing attributes, and then merge the multiple billing results in each merged group to obtain multiple merged accounting results corresponding to the multiple merged groups. For example, if the merged billing attributes are January 1, January 2, and January 3, then multiple billing results on January 1 will be combined into one merged accounting result, multiple billing results on January 2 will be combined into one merged accounting result, and multiple billing results on January 3 will be combined into one merged accounting result. The above example is for illustrative purposes only and is not specifically limited in this application.

[0127] Optionally, the first merging unit 430 can be deployed on multiple instances, with each instance used to merge multiple billing results for a merged group, and each instance generating a single merged accounting result. It should be understood that generating merged accounting results in parallel across multiple instances can improve the efficiency of merged accounting. In a specific implementation, the aforementioned instances can be physical machines, virtual machines, or containers, and this application does not impose specific limitations.

[0128] It should be noted that one or more combined billing attributes can filter out one or more groups of billing results. Multiple billing results from a combined group are assigned to a single computing device for processing. For example, if there are 1,000 billing results on January 1st, 500 transactions can be combined by instance A and 500 transactions by instance B.

[0129] In one possible implementation, the reconciliation system 400 can establish a microservice architecture, and assign billing merging tasks to each instance through the microservice architecture. A billing merging task is used to merge multiple billing results of a merge group. The microservice architecture includes multiple instances, each of which is used to perform a specific task. Each instance can run in a physical machine, a virtual machine, or a container. Furthermore, the microservice architecture can also be combined with sharding stream technology to generate multiple billing merging tasks based on the merged billing attributes, and assign the multiple billing merging tasks to each microservice instance, so that multiple instances complete multiple billing merging tasks in parallel.

[0130] It should be understood that sharded streaming technology can be used to reasonably distribute billing consolidation tasks, ensuring that the processing pressure of each billing consolidation task is moderate, avoiding excessive processing burden of a single billing consolidation task, and realizing dynamic scaling of instances through microservice architecture. The number of instances can be automatically adjusted according to the billing consolidation tasks to better meet business changes and development.

[0131] In a specific implementation, the sharded stream technology can generate billing merging tasks in a variety of ways. For example, after screening out multiple billing results based on the merged billing attributes, the unique identifier of each billing result (such as the transaction number) is modulo-sharded to ensure that multiple billing results can be evenly distributed on different instances, thereby avoiding the billing results of a certain ID range being concentrated on the same instance, resulting in performance bottlenecks. After the allocation is completed, the multiple billing results allocated to each instance are the billing results of the same group, and the billing results of the group of billing results are merged to form the billing merging task that the instance needs to complete. It should be understood that the above examples are for illustration, and the sharded stream technology can also use other methods to generate billing merging tasks, such as based on distributed scheduling task systems, message queues, load balancers and other technical means to achieve a reasonable division of billing merging tasks, which is not specifically limited in this application.

[0132] In specific implementations, the microservice architecture can achieve dynamic scaling in a variety of ways, such as using a container orchestration platform to automate the deployment, expansion, and management of instances (containers). For example, the vertical pod autoscaler (PVA) of k8s can automatically adjust the number of microservice instances based on defined metrics (such as CPU usage, memory usage, etc.), ensuring that more requests are processed during peak hours and reducing resource usage during low hours. It should be understood that the above examples are for illustration purposes only, and the microservice architecture can also achieve dynamic scaling in more ways, which is not specifically limited in this application.

[0133] In another possible implementation, the reconciliation system 400 can be based on a big data platform and, based on the combined billing attributes, filter out multiple groups of billing results, and then merge the multiple groups of billing results to obtain multiple combined billing results. The above-mentioned big data platform may include but is not limited to HiveSQL, SAP RSQL, etc. Specifically, batch processing or stream processing can be used to obtain multiple billing results, transaction attribute tables, bitmaps and other data and store them in a data warehouse of a big data platform such as Hive or Spark. Big data platforms such as Hive and SAP RSQL provide a query language similar to SQL to facilitate complex data analysis, so that the big data platform can filter out multiple groups of billing results based on different combined billing attributes, complete the merging of multiple billing results of each merged group, and generate a merged billing result.

[0134] It should be understood that the above examples provide two possible implementation methods for obtaining the combined billing results. The present application can also obtain the combined billing results through other implementation methods, which are not specifically limited in the present application. Moreover, combined billing can also be achieved through a mixed solution of multiple implementation methods. The combined solution can be flexibly set according to the actual application, which is not specifically limited in the present application.

[0135] The receiving unit 440 is configured to obtain the deduction results of multiple transactions sent by the banking system 300 .

[0136] In a specific implementation, after the bank system 300 completes the payment channel deduction, it will generate a deduction result and then send the deduction result to the third-party payment platform so that the third-party payment platform can complete the reconciliation of the payment channel. Among them, the deduction results of multiple transactions may include a single deduction result for each transaction. Generally, each single deduction result may include the transaction attributes and deduction details of the transaction. The transaction attributes can refer to the aforementioned content, such as the transaction time, transaction number, payment channel code, bank code, transaction amount, transaction status, transaction type, currency type, merchant code, settlement mode, etc. of each transaction combined. The deduction details may include the fee categories and the amounts of each fee included in the channel cost deducted by the bank. The specific details can be determined according to the actual application scenario and are not specifically limited in this application.

[0137] It should be noted that the deduction results sent by the bank system 300 may include the deduction results of multiple transactions, which can be determined specifically based on the actual business operations of the bank system 300. For example, the bank system 300 may send the deduction results of M transactions to the third-party payment platform every time M deductions are completed, or it may send the deduction results of multiple transactions completed within an hour every hour, or it may send the deduction results of multiple transactions completed on the same day at a fixed time every day, such as 12 o'clock in the morning, or it may send monthly bills every month, quarterly bills every quarter, etc. The number of transactions included in the deduction results may be determined specifically based on actual business needs.

[0138] It should be noted that the bank system 300 is a general term for the transaction system maintained by the financial institution that completes the deduction. It can be the system of a bank, such as the transaction system of Branch Z in District Y of City X, or it can be the system of a type of bank, such as the ICBC system, the Bank of Communications system, the Agricultural Bank of China system, etc. It can also be the system of multiple banks, such as the UnionPay system, the China National Nets UnionPay system, the Bank-Nets UnionPay system, etc. This application does not make any specific limitations.

[0139] Optionally, the receiving unit 440 can generate a transaction attribute table of the deduction result and a bitmap corresponding to the deduction result based on the deduction result. The description of the transaction attribute table and the bitmap can refer to the relevant description of the aforementioned first merging unit 430, which will not be repeated here.

[0140] The second merging unit 450 is configured to merge the deduction results of multiple transactions according to the multiple transactions corresponding to the combined billing result, to obtain a combined deduction result corresponding to the combined billing result.

[0141] In a specific implementation, the second merging unit 450 can merge the deduction results of multiple transactions based on the combined billing attributes used by the first merging unit 430 to obtain a combined deduction result, so that the multiple transactions corresponding to the combined deduction result are the same as the multiple transactions corresponding to the combined billing result, and the multiple transactions corresponding to the multiple billing results merged by the combined billing result are the multiple transactions corresponding to the combined billing result. Simply put, the merging granularity of the combined billing result and the combined deduction result must be consistent so that the two accounts with the same granularity can complete reconciliation.

[0142] Similarly, when the second merging unit 450 merges multiple deduction results, it first merges the various handling fees included in the deduction results of multiple transactions to obtain a merged deduction amount, and then generates a merged deduction result based on the merged deduction amount. The merged deduction result not only includes the merged deduction amount, but also includes some information required for channel cost reconciliation, and has the same category as the merged accounting result generated by the first merging unit 430. For example, each merged deduction result includes at least the transaction attributes and deduction information of each merged transaction. The transaction attributes can be information such as the transaction time and transaction number of each transaction, and the deduction information can be the deduction details of each transaction, etc., so as to complete the channel cost reconciliation.

[0143] Similarly, the combined deduction amount is similar to the combined billing amount. The combined deduction amount includes the total amount of multiple categories. Multiple categories include the total amount of channel costs for multiple transactions, and also include the total amount of one or more fees in the channel costs, such as the total clearing fees, total settlement fees, total network fees, total technical support fees, total risk management fees, total compliance and regulatory fees, total promotion and duration fees, total brand fees, etc., or the combined fees screened out using some billing attributes can also be used as a category, such as the total amount of channel costs that need to be paid to Bank A in multiple transactions, etc. The specific categories included in the combined deduction amount can be determined based on the categories included in the combined billing amount, and this application does not make specific limitations.

[0144] It should be understood that the fields contained in the combined deduction results and the combined billing results are similar. Because the two need to be reconciled, the process of generating the combined deduction results is similar to the process of generating the combined billing results. For example, the combined deduction results can use the same template information as the combined billing results, or the template information used by the two has common fields. During reconciliation, the values ​​under the common fields can be matched, which will not be repeated here.

[0145] Similarly, the second merging unit 450 can also be deployed on one or more instances, each instance being used to complete a deduction merging task. Each deduction merging task is used to merge multiple deduction results in a merge group to obtain the corresponding merged deduction result. One or more merged billing attributes can filter out multiple groups of deduction results. For example, if there are 1,000 deduction results on January 1st, 400 of which are merged by instance C and 600 by instance D.

[0146] It should be noted that the granularity of the division of deduction merging tasks by the second merging unit 450 is consistent with the granularity of the division of billing merging tasks by the first merging unit 430. That is, one deduction merging task can correspond to one billing merging task. The multiple transactions processed by the deduction merging task and the multiple transactions processed by the corresponding billing merging task are the same group of transactions. The billing merging task merges the billing results of this group of transactions, and the deduction merging task merges the deduction results of this group of transactions. For example, if the first merging unit 430 merges the billing results of 200 transactions, then the second merging unit 450 also needs to merge the deduction results of these 200 transactions to obtain a merged deduction result corresponding to the merged billing result.

[0147] It should be understood that the method for obtaining the merged deduction results is similar to the method for obtaining the aforementioned merged accounting results. For details, please refer to the relevant description of the aforementioned first merging unit 440. For example, the second merging unit 450 can also distribute the deduction merging tasks to each instance through the microservice architecture, and reasonably divide the deduction merging tasks through the sharding flow technology. The parameters of the microservice architecture and the sharding flow technology used by the second merging unit 450 are consistent with those used by the first merging unit 430, ensuring that the final merged deduction results and merged billing results are the merged results of the same group of transactions. No further details will be given here.

[0148] It should be noted that after receiving the deduction result sent by the banking system 300, the receiving unit 440 needs to generate a transaction attribute table and a bitmap based on the deduction result, so that the subsequent second merging unit 450 can also read the deduction result that needs to be merged based on the transaction attribute table and the bitmap. Figure 1 only shows the bitmap generated by the single billing unit 420, but the actual storage device 480 also stores the bitmap and transaction attribute table generated by the receiving unit 440 based on the deduction result. This application does not limit this. It should be understood that for the sake of distinction, the bitmap of the billing result is referred to as the billing bitmap, and the bitmap of the deduction result is referred to as the deduction bitmap.

[0149] Optionally, the reconciliation system 400 may establish a mapping relationship between the consolidated deduction results and the consolidated accounting results, and a mapping relationship may be established between the consolidated deduction results and the consolidated accounting results of the same consolidated group.

[0150] The reconciliation unit 460 is used to complete the channel cost reconciliation according to the corresponding consolidated accounting results and consolidated deduction results to obtain a reconciliation result.

[0151] It should be understood that since the second merging unit 450 and the first merging unit 430 use the same merging granularity to complete the merging of the deduction results and the billing results, the merged accounting results and the merged deduction results corresponding to the transactions in the same merged group can be reconciled to obtain the reconciliation results. The merged settlement results and the merged deduction results corresponding to transactions that do not belong to the same group cannot be reconciled.

[0152] Optionally, the reconciliation result includes the difference information between the consolidated accounting result and the corresponding consolidated deduction result. The difference information may include the difference between the consolidated billing amount and the consolidated deduction amount. The difference can also be further subdivided, including the difference between the total amount of handling fees of multiple categories, such as the difference in the total amount of clearing fees, the difference in the total amount of settlement fees, the difference in the total amount of network fees, the difference in the total amount of technical support fees, etc. It also includes the difference in consolidated handling fees screened using some billing attributes, such as the difference in the total amount of channel costs that need to be paid to Bank A in multiple transactions, etc. The specific details of the difference information can be determined according to the actual business scenario, and this application does not make specific limitations.

[0153] It should be understood that if the combined deduction amount and the combined billing amount are the same, it means that the billing and deduction of multiple transaction data of this group of transactions are consistent. The transaction data of this group of transactions can be written off, and there is no need to reconcile each transaction in the group of transactions. In this way, the efficiency of reconciliation can be improved by merging multiple transactions and then reconciling the channel costs.

[0154] Optionally, the reconciliation result includes not only the above-mentioned difference information, but also other information, such as the transaction attributes of multiple transactions involved in the reconciliation, such as the time of reconciliation, etc. The specific content of the reconciliation result can be determined according to actual business needs, and this application does not make specific limitations.

[0155] The analysis unit 470 is used to obtain warning information based on the reconciliation result and the warning strategy, and send the warning information to the client 100 for processing.

[0156] Optionally, the warning strategy may include a difference threshold. If the difference in the difference information exceeds the difference threshold, a warning message is generated. In a specific implementation, the number of difference thresholds can be one or more, with different difference thresholds corresponding to different categories of handling fee differences. For example, the difference between the total billing amount and the total deduction amount corresponds to a difference threshold, and the difference in the total handling fee of a certain category corresponds to a difference threshold. This application does not impose specific restrictions.

[0157] Optionally, when the difference in the difference information does not exceed the difference threshold, the transaction data for the group of transactions corresponding to the difference can be written off. It should be understood that if the difference is small, such as only a few cents or a few dollars, it can be ignored and no reconciliation is required. For example, after 1,000 transactions are merged and the channel cost reconciliation is performed, it is found that the combined billing amount and the combined deduction amount differ by 1 dollar. Reconciling all 1,000 transactions one by one for this 1 dollar is a waste of manpower, material and financial resources. In this case, by setting a difference threshold, such transactions with small, negligible differences can be directly written off, thereby improving the efficiency of channel cost reconciliation.

[0158] Optionally, when the difference in the difference information exceeds the difference threshold, the analysis unit 470 can generate an early warning message, which may include the above-mentioned difference information, and may also include some other information for the management user to locate and analyze the cause of the difference. For example, other information may include reconciliation time, transaction status, difference details, etc., wherein the difference details may include the transaction data of the transaction with the difference, and information on which specific part of the transaction fee cannot be reconciled, so that the management user can locate the cause of the reconciliation failure.

[0159] In a specific implementation, when determining the difference details, the billing result and deduction result of each transaction can be read through the billing bitmap and deduction bitmap, and then the billing result of each transaction can be compared with the deduction result to determine the transactions with differences. Then, for each transaction with differences, the billing and deduction of each handling fee can be further checked to see if they are consistent, so as to determine which handling fee of which transaction cannot be reconciled, and generate difference details for the management user to locate the cause of the reconciliation failure. The above examples are for illustration purposes only, and this application does not limit the specific content of the difference details.

[0160] It should be understood that if the traditional channel cost reconciliation method is used, the billing result of each transaction needs to be checked with the deduction result of each transaction. If a transaction is not reconciled, it is necessary to manually analyze the cause of the problem and then adjust the account to make the billing result and the deduction result correct, which is inefficient. This application merges multiple billing results of multiple transactions, merges multiple deduction results, and then checks the merged billing result with the merged deduction result. If the difference between the two is small, the multiple transactions can be directly written off. If the difference is large, the management user will determine the cause of the difference based on the multiple difference transactions in the difference details. This method can improve the efficiency of reconciliation and does not require checking every bill.

[0161] Furthermore, after the management user obtains the early warning information through the client 100, he can locate the reason for the reconciliation failure based on the difference details in the early warning information, and then adjust the billing model, update the billing bitmap and the detailed table corresponding to the billing bitmap, obtain the information merge accounting result, and reconcile the merged accounting result with the merged deduction result. If the difference is lower than the threshold, it will be written off. If the difference is still higher than the threshold, the management personnel will need to readjust the billing model. It should be understood that in this method, the user only needs to query the account and then locate the reason for the reconciliation failure and adjust the billing model. There is no need to adjust thousands of inconsistent accounts. Adjustment is a very complicated step and is very dependent on manual operation. The reconciliation method provided by this application does not require adjustment. The entire reconciliation process can be automated. The management personnel only need to analyze and locate the reason for the reconciliation failure and adjust the billing model, which greatly reduces the pressure of manual processing and improves the work efficiency of the management personnel.

[0162] For example, when checking 1,000 channel cost accounts using the traditional method, the billing and deduction results of each of the 1,000 transactions need to be checked one by one. After 200 erroneous bills are found, the management personnel need to manually locate the causes of the 200 erroneous bills one by one. For example, if the cause of the inconsistency is determined to be a temporary adjustment of the bank's fee percentage, the management personnel need to adjust the channel cost accounts of the 200 transactions according to the new fee percentage based on the 200 billing results. Using the reconciliation method provided by this application, after the reconciliation system 400 automatically obtains the billing results of 1,000 transactions through the billing model, multiple instances parallelly calculate the combined accounting results and combined deduction results of each 200 transactions, and then automatically reconcile 5 groups of combined accounting results and combined deduction results. If the difference between the 200 transactions that failed to reconcile is lower than the threshold, they can be directly and automatically written off, greatly accelerating the reconciliation efficiency; if the difference between the 200 transactions is higher than the threshold, a difference detail can be generated and displayed to the management user. After the management user manually locates the cause, he only needs to modify the billing model, and the reconciliation system 400 can automatically update the combined accounting results and automatically write off the 1,000 transactions. In this way, the management user does not need to adjust the accounts one by one, but only needs to modify the billing model to complete the write-off of the channel cost reconciliation. The entire process is very simple and fast, which improves the user experience.

[0163] In summary, the present application provides a reconciliation system, which can obtain transaction data of multiple transactions from a payment channel system, determine the billing result of the payment channel cost of each transaction based on a billing model, and then obtain the deduction result of the payment channel cost of each transaction from a bank system, and then merge the billing results of multiple transactions to obtain a merged billing result, merge the deduction results of multiple transactions to obtain a merged deduction result, determine the difference between the merged billing result and the merged deduction result, and when the difference exceeds the warning threshold, send a warning message to the management user to instruct the user to update the billing model, so that the channel cost can be reconciled in a merged reconciliation, without the need to reconcile one by one, thereby improving the reconciliation efficiency. At the same time, the management user can update the billing model according to the warning information, and no longer need to adjust the accounts one by one, thereby improving the reconciliation efficiency, reducing labor costs, and improving the user experience.

[0164] The above describes in detail the reconciliation system provided by the present application. The following explains the reconciliation method provided by the present application in conjunction with Figures 2 to 8.

[0165] FIG2 is a flowchart of steps of a reconciliation method provided by the present application. The reconciliation method can be applied to the reconciliation system 400 shown in FIG1 . As shown in FIG2 , the method may include the following steps:

[0166] S201: The client 100 sends a request for configuring a billing model to the reconciliation system 400. This step can be implemented by the configuration unit 410 in the embodiment of FIG1 .

[0167] Optionally, the configuration request may include information about the billing model requested by the user. The information about the billing model may include billing elements and billing rules. Each billing rule corresponds to a set of billing elements. Based on the billing elements contained in each transaction data, the billing rules that need to be used for the transaction data can be determined.

[0168] Optionally, the billing elements may include some necessary information for determining the billing rules to be used for transaction data, such as payment channel name, payment channel product name, institution code, channel type, channel subtype, bank name, etc. For details, please refer to the relevant description of the embodiment of Figure 1, which will not be repeated here.

[0169] Optionally, the billing rules may include the billing method of the channel handling fee. For example, the billing rules may include the billing type, the fee effective time, and the billing mode. The billing type is used to distinguish the billing method, the fee effective time is used to define the effective time range of the billing, and the billing mode is used to describe the billing details under the billing type. The billing type, the fee effective time, and the billing mode can constitute a complete billing rule. For details, please refer to the relevant description of the embodiment of Figure 1, which will not be repeated here. Among them, the billing type includes billing methods such as single billing, single gradient billing, and amount cumulative gradient billing. The fee effective time may include effective time such as immediate effect, daily effect, and monthly effect. The billing mode may include fixed fees, percentage fees, mixed billing, etc. For details, please refer to the relevant description of the embodiment of Figure 1, which will not be repeated here. The billing model may also include more content, which will not be given examples here one by one.

[0170] Optionally, the reconciliation system 400 can pre-generate a variety of billing elements and billing rules, from which the management user can select billing elements and billing rules for mapping, obtain the corresponding relationship between the billing elements and billing rules, and complete the configuration of the billing model. Specifically, the management user can use a graphical user interface (GUI) to initiate a configuration request, and the client 100 can display the selectable billing elements and billing rules to the management user. The reconciliation system 400 can generate a billing model based on the billing elements and billing rules selected by the management user and store it in the storage device 480, so that when the transaction data is subsequently billed, billing can be completed according to the billing model.

[0171] For example, FIG3 is an example diagram of a configuration interface provided by the present application. The client 100 can display this interface to the management user, from which the management user can select the billing elements and billing rules to be configured, complete the configuration of the billing model, and then initiate a configuration request containing the billing model to the reconciliation system 400. As shown in FIG3, the configuration interface may include a billing element configuration area 310, a billing rule configuration area 320, and a confirmation control 330.

[0172] The billing element configuration area 310 can display multiple billing elements. For example, Figure 3 shows some possible billing elements. In the example shown in Figure 3, the channel product name, channel name, branch name, organization code, channel type, channel subtype, bank group, and bank name can be billing elements of the transaction attribute category, while the settlement mode, fee collection method, and fee collection cycle can be billing elements of the billing attribute category. Among them, transaction attributes are related to transaction data and describe some fields and information of the transaction itself. Billing attributes are related to the channel cost billing process and describe some fields and information of channel cost billing. For details, please refer to the relevant description in the embodiment of Figure 1, which will not be repeated here.

[0173] The billing rule configuration area 320 can display multiple billing rules. For example, Figure 3 shows some possible billing rules. In the example shown in Figure 3, the billing types include single billing, single gradient billing, and amount cumulative gradient billing. Among them, taking the selection of single billing as an example, the parameters that need to be configured include the effective time of the application fee, billing mode, handling fee amount, brand fee amount, network server amount, payable business participation price amount, etc. It should be understood that if single gradient billing is selected, the parameters that need to be configured in the billing rules in Figure 3 may change, and this application does not make specific restrictions.

[0174] The confirmation control 330 is used for the user to confirm the configured billing rules and billing elements. After the user clicks the confirmation control 330, the client 100 can send a configuration request carrying the above billing rules and billing elements to the reconciliation system 400.

[0175] It should be understood that this application pre-configures billing elements and billing rules, and then allows the administrator to configure the billing model through a selection method, making the model configuration simpler, faster, and more flexible, thereby improving the user experience. Of course, the administrator can customize the billing model by modifying the configuration file, importing the model through the GUI, etc., and this application does not specifically limit this.

[0176] Optionally, the billing model generated by the reconciliation system 400 according to the configuration request is a calculation model. The billing result can be obtained by inputting the transaction data into the billing model. The billing model can match the transaction data with the billing elements in the billing model, determine the billing rules corresponding to the transaction data, and then use the billing rules to complete the billing. The billing model may include the types of fees that need to be calculated and the corresponding fee calculation methods. The types of fees include channel fees, clearing fees, settlement fees, network fees, technical support fees, risk management fees, compliance and regulatory fees, promotion and duration fees, brand fees, etc. The fee calculation method can be determined according to the specific business scenario, and this application does not make specific limitations.

[0177] S202A: The payment channel system 200 sends transaction data of multiple transactions to the reconciliation system 400. This step can be implemented by the single transaction billing unit 420 in the embodiment of FIG1.

[0178] Optionally, after a mall user places an order through the mall system of a third-party payment platform, the mall system may generate a payment instruction and then send the payment instruction to the payment channel system 200. The payment channel system 200 generates transaction data based on the payment instruction and then sends the transaction data to the single billing unit 420 of the reconciliation system 400 of the third-party payment platform. At the same time, the transaction data is sent to the bank system 300 to complete the deduction of the channel handling fee. After the bank system 300 generates the channel deduction bill, it feeds it back to the reconciliation system 400, so that the reconciliation system 400 can complete the channel cost reconciliation based on the transaction data and the channel deduction bill.

[0179] In a specific implementation, a payment instruction is a generated payment instruction that may include information such as the payment amount, payment method, payee information, payment initiator information, transaction description, transaction serial number, and payment timestamp. Transaction data is generated by the payment channel system 200 based on the payment instruction. The transaction data may include transaction data for multiple transactions, each of which includes transaction amount, transaction status, transaction time, payment serial number, payment channel information, payment channel serial number, merchant information, and mall user information. The above examples are for illustrative purposes only. Payment instructions and transaction data may include more information, which is not fully detailed here.

[0180] S202B: The payment channel system 200 sends transaction data of multiple transactions to the bank system 300. This step can be implemented by the payment channel system 200 and the bank system 300 in the embodiment of FIG1.

[0181] It should be understood that the transaction data is the same as the transaction data of S202A, but the quantity of transaction data may be the same or different, which can be determined according to actual business needs and is not specifically limited in this application.

[0182] S203: The reconciliation system 400 determines the billing result for each transaction based on the billing model. This step can be implemented by the single-transaction billing unit 420 in the embodiment of FIG1 .

[0183] Optionally, reconciliation system 400 can determine the transaction attributes of each transaction based on the transaction data of each transaction and generate a transaction attribute table. The transaction attribute table includes multiple fields, each field representing a transaction attribute, and each row of data corresponds to a batch of transaction data with multiple identical transaction attributes. In this way, reconciliation system 400 can determine the corresponding billing model for each batch of transaction data based on the transaction attributes of each row of data, and determine the billing results for each transaction in each batch of transaction data based on the corresponding billing model. It should be understood that merging multiple transactions with the same transaction attributes allows a row of data in the transaction attribute table to be billed for channel costs using the same billing model, thereby improving billing efficiency.

[0184] In a specific implementation, transaction attributes are used to describe the relevant characteristics of the transaction data. For example, transaction attributes may include transaction time, payment channel code, bank code, transaction amount, transaction status, transaction type, currency type, merchant code, settlement mode, etc. It should be understood that the above examples of transaction attributes are for illustrative purposes only and are not specifically limited in this application. It should be noted that each transaction can be table data, so transaction attributes can be understood as fields contained in the table data.

[0185] Optionally, since the amount of transaction data is often very large, in order to ensure that the data can be read efficiently when reading the transaction data to calculate the channel cost, an index can be assigned to each batch of transaction data. Specifically, an additional index field can be maintained in the transaction attribute table. The index can be the hash value of multiple fields, so that each row of data can correspond to an index. The index can be used to query each row of transaction data, thereby improving the efficiency of data query.

[0186] Alternatively, if multiple rows of transaction data with the same hash value exist, the rows corresponding to the same hash value can be concatenated into a linked list, with each row corresponding to a node in the linked list. Specifically, an additional field for identifying the linked list nodes can be maintained in the transaction attribute table, such as a linked list node sequence or a preceding node sequence. This allows multiple rows of transaction data with the same hash value to be concatenated into a linked list, with each row corresponding to a different linked list node. Thus, when querying data, if multiple rows of transaction data are obtained based on an index, the entire linked list corresponding to the hash value can be read first. Then, following the node order described by the linked list node field, the transaction data corresponding to each linked list node can be traversed sequentially until the transaction data meeting the query criteria is found, thereby avoiding index invalidation due to hash conflicts. The linked list nodes can be arranged in the order in which they were added. Examples of linked lists and index fields can be found in the aforementioned Tables 1 and 2, and are not repeated here.

[0187] Optionally, the reconciliation system 400 can determine the billing result of the channel cost for each transaction in each batch of transaction data based on the transaction attribute table. The billing result may include a detailed description of the channel cost for each transaction and a clearing result. For a description of the channel cost details and clearing results, please refer to the relevant description of the embodiment in FIG1 and are not repeated here. In a specific implementation, when determining the billing result for each batch of transaction data, the reconciliation system 400 can match the transaction data with the billing elements and corresponding billing rules in the billing model configured in S201, determine the billing rules to be used for the transaction data, and then determine the billing result for the transaction data based on the billing rules.

[0188] Optionally, after obtaining the billing result for each transaction, the reconciliation system 400 may generate a billing bitmap corresponding to the billing result for each transaction. The bitmap includes multiple bits, each of which is used to describe a billing attribute in the billing result, and the value of the bit is used to indicate whether the billing attribute exists. The billing attributes are used to describe relevant features in the billing result. The billing attributes include transaction attributes of the transaction data corresponding to the billing result, attributes related to channel cost details in the billing result, and attributes related to clearing results. This application does not specifically limit this.

[0189] Furthermore, the reconciliation system 400 can also establish a detailed table based on the bitmap, wherein a mapping relationship exists between the detailed table and the bitmap, with one bitmap corresponding to one detailed table. The bitmap is used to record the billing attributes included in the billing result, and the detailed table is used to record the values ​​corresponding to the billing attributes. For example, if the bitmap records that the billing result includes a network service fee, then the detailed table corresponding to the bitmap records that the amount of the network service fee is 2 yuan. It should be noted that the detailed table can also be stored in the storage device 480, and the mapping relationship between the detailed table and the bitmap is also stored in the storage device 480.

[0190] It should be understood that the billing results of each transaction are recorded through a bitmap, including the billing attributes contained in the billing results of each transaction, and then the specific value of each billing attribute is recorded through a detailed table. Under this implementation method, the bitmap can not only effectively save storage space, but also quickly filter out billing results that meet specific billing attributes through masks, bit operations, etc. The retrieval method is faster, which improves data query efficiency. At the same time, the bitmap is also easy to expand. When adding new billing attributes, the new billing attributes can be supported by expanding the bitmap and detailed table without modifying the entire data structure, making the billing results easier to maintain.

[0191] For example, Figure 4 is an example diagram of a bitmap provided in this application. In the example shown in Figure 4, each bit of the bitmap is used to indicate a billing attribute. If the billing result includes the billing attribute, the value of the bit is 1; if the billing attribute is not included, the value of the bit is 0.

[0192] In the example shown in Figure 4, the billing attributes indicated by each bit can be divided into three types: settlement mode type, fee type, and billing type. The settlement mode type includes billing attributes such as no settlement involved, full settlement, and netting settlement. The fee type includes billing attributes such as business participation price, brand fee, network service fee, and bank handling fee. The billing type includes billing attributes such as amount accumulation ladder, package gradient, and single-transaction gradient. For example, Figure 4 shows an example bitmap: 1001101101, indicating that the settlement mode type of the billing result is no settlement involved, the fee type includes business participation price, brand fee, and bank handling fee, and the billing type is amount accumulation ladder and single-transaction gradient.

[0193] For another example, Figure 5 is an example diagram of another bitmap provided by this application. The difference between Figure 5 and Figure 4 is that the multiple bits in the bitmap shown in Figure 4 are arranged horizontally according to different types, the bitmap shown in Figure 4 is similar to a vector, and the multiple bits in the bitmap shown in Figure 5 are arranged vertically according to different types, similar to a matrix. The multiple bits in the first row of Figure 5 are used to indicate the settlement mode type, the multiple bits in the second row are used to indicate the fee type, and the multiple bits in the third row are used to indicate the billing type. Therefore, the bitmap 1001101101 shown in Figure 4 can also be represented as the matrix shown in Figure 5. It should be understood that Figures 4 and 5 are used for illustration purposes only and are not specifically limited in this application.

[0194] Furthermore, the detailed table corresponding to the bitmap shown in Figures 4 and 5 can record details of the business participation price, brand fee, bank and handling fee, as well as parameters of the cumulative step in the billing type, parameters of the single step, etc. When reading the billing result of each transaction, the user can send a query request carrying the billing attribute. The reconciliation system 400 can read the bitmap and the corresponding detailed table containing the billing attribute according to the billing attribute in the query request, thereby reading the billing result requested by the user.

[0195] It should be noted that in the example shown in Figure 4, the bitmap has only one row, which is similar to a vector. In the specific implementation, the bitmap can also have multiple rows, similar to a matrix. Each bit of each row can be used to indicate a billing attribute, and each row can represent a class of billing attributes. For example, in the example shown in Figure 4, the first row can be multiple bits of the settlement mode type, the second row can be multiple bits of the fee type, and the third row can be multiple bits of the billing type. Figure 4 is used for illustration and this application does not make specific limitations.

[0196] S204: The banking system 300 sends the deduction results of the multiple transactions to the reconciliation system 400. This step can be implemented by the receiving unit 440 in the embodiment of FIG1.

[0197] In a specific implementation, after the bank system 300 completes the payment channel deduction, it will generate a deduction result, and then send the deduction result to the third-party payment platform so that the third-party payment platform can complete the reconciliation of the payment channel. Among them, the deduction results of multiple transactions may include a single deduction result for each transaction. Generally, each single deduction result may include the transaction attributes and deduction details of the transaction. The transaction attributes can refer to the aforementioned content, such as the transaction time, transaction number, payment channel code, bank code, transaction amount, transaction status, transaction type, currency type, merchant code, settlement mode, etc. of each transaction combined. The deduction details may include the fee categories and the amounts of each fee included in the channel cost deducted by the bank. The specific details can be determined according to the actual application scenario and are not specifically limited in this application.

[0198] Optionally, the reconciliation system 400 may generate a transaction attribute table of the deduction result and a deduction bitmap corresponding to the deduction result based on the deduction result. For descriptions of the transaction attribute table and the bitmap, reference may be made to the relevant description of S203 above, which will not be repeated here.

[0199] S205: The reconciliation system 400 combines the billing results of multiple transactions to obtain a combined billing result, and combines the deduction results of multiple transactions to obtain a combined deduction result. This step can be implemented by the first combining unit 430 and the second combining unit 450 in the embodiment of FIG1 .

[0200] The following describes in detail the process of obtaining the combined billing results. The process of obtaining the combined deduction results is similar and will not be repeated here.

[0201] Optionally, the reconciliation system 400 can merge multiple billing results containing the same combined billing attribute to obtain a combined accounting result, wherein the combined billing attribute can be set by the management user or set by default by the reconciliation system 400. In a specific implementation, the reconciliation system 400 can generate a mask based on the combined billing attribute, and use the mask to perform a bitwise AND operation on the billing bitmap of each transaction. If the result of the bit after the operation is non-zero, it means that the billing result corresponding to the billing bitmap contains the billing attribute represented by the bit. If the result of the bit after the operation is zero, it means that the billing result does not contain the billing attribute represented by the bit. Based on the result of the mask operation, a bitmap that meets the conditions can be obtained, and then, based on the detailed table corresponding to the bitmap, multiple billing results that meet the combined billing attribute are obtained to obtain a combined accounting result. It should be noted that if the bit corresponding to the combined billing attribute does not exist in the bitmap, multiple transaction data corresponding to the combined billing attribute can be obtained from the transaction attribute table, and then the bitmap corresponding to the above multiple transaction data is obtained to complete the combined accounting.

[0202] FIG6 is a diagram showing an example of the steps for reading a billing bitmap containing a combined billing attribute based on a mask provided by the present application. Still taking the bitmap format shown in FIG4 as an example, assuming that bitmap 1 is 1001101101, bitmap 2 is 0100111011, and bitmap 3 is 0010011001. Assuming that mask 1 is 0000100000, it means that the billing results whose fee types include brand fees need to be filtered out, and mask 2 is 0000010000, it means that the billing results whose fee types include network service fees need to be filtered out. Then, after operating bitmaps 1 to 3 using mask 1, bitmap 1 and bitmap 2 can be filtered out. After operating bitmaps 1 to 3 using mask 2, bitmap 2 and bitmap 3 can be filtered out. It should be understood that reading the billing results containing a certain billing attribute by operating the bitmap using a mask does not require comparing the values ​​of each field one by one, which is simpler and faster, and improves the efficiency of data reading. At the same time, the compact storage form of bitmap can reduce the storage space requirements of data and save memory.

[0203] Optionally, after reading multiple billing results that need to be merged through the bitmap and the merged billing results, the reconciliation system 400 first merges the channel costs of multiple transactions to obtain a merged billing amount, and then generates a merged accounting result based on the merged billing amount. The final generated merged accounting result may include the merged billing amount and other information, wherein the merged billing amount includes the total amount of multiple categories, the multiple categories include the total amount of channel costs of multiple transactions, and also includes the total amount of one or more handling fees in the channel costs. Other information may include some information required for channel cost reconciliation, such as transaction information, billing results, merged information, channel cost information, total information, etc., which is not specifically limited in this application.

[0204] Optionally, the reconciliation system 400 can obtain multiple merge groups based on different merged billing attributes, and then merge the multiple billing results in each merge group to obtain multiple merged accounting results corresponding to the multiple merged groups. Furthermore, the reconciliation system 400 can be deployed on multiple instances, one instance is used to merge the multiple billing results of a merged group, and one instance obtains one merged accounting result. It should be understood that by generating merged accounting results in parallel by multiple instances, the efficiency of merged accounting can be improved. In a specific implementation, the above-mentioned instance can be a physical machine, or a virtual machine, or a container, and this application does not make specific limitations. It should be noted that one or more merged billing attributes can filter out one or more groups of billing results, and the multiple billing results of a merged group are assigned to a computing device for processing. One or more merged billing attributes can filter out multiple groups of billing results. For example, if there are 1,000 multiple billing results on January 1, 500 transactions can be merged by instance A and 500 transactions can be merged by instance B.

[0205] In one possible implementation, the reconciliation system 400 can establish a microservice architecture, and assign billing merging tasks to each instance through the microservice architecture. A billing merging task is used to merge multiple billing results of a merge group. The microservice architecture can also be combined with the sharding flow technology to generate multiple billing merging tasks according to the merged billing attributes, and assign multiple billing merging tasks to each microservice instance, so that multiple instances complete multiple billing merging tasks in parallel. In a specific implementation, the sharding flow technology can generate billing merging tasks in a variety of ways, such as taking a module and sharding the unique identifier of each billing result (such as a transaction number) to ensure that multiple billing results can be evenly distributed on different instances, thereby avoiding the billing results of a certain ID range from being concentrated on the same instance, resulting in performance bottlenecks. The sharding flow technology can also use other methods to generate billing merging tasks, such as based on distributed scheduling task systems, message queues, load balancers and other technical means to achieve reasonable division of billing merging tasks, which is not specifically limited in this application. Microservice architecture can achieve dynamic scaling in a variety of ways, such as using a container orchestration platform to automate the deployment, expansion, and management of instances (containers), which is not specifically limited in this application.

[0206] In another possible implementation, the reconciliation system 400 can filter multiple sets of billing results based on the combined billing attributes based on a big data platform, and then combine the multiple sets of billing results to obtain multiple combined billing results. The big data platform may include, but is not limited to, HiveSQL, SAP RSQL, etc.

[0207] It should be understood that the above examples provide two possible implementation methods for obtaining the combined billing results. The present application can also obtain the combined billing results through other implementation methods, which are not specifically limited in the present application. Moreover, combined billing can also be achieved through a mixed solution of multiple implementation methods. The combined solution can be flexibly set according to the actual application, which is not specifically limited in the present application.

[0208] Similarly, you can combine the deduction results of multiple transactions based on the consolidated billing attribute to obtain a consolidated deduction result. However, it's important to note that the granularity of the consolidated billing result and the consolidated deduction result must be consistent. This ensures reconciliation between the two accounts at the same granularity. Therefore, the fields contained in the consolidated deduction result and the consolidated billing result are similar, allowing you to match values ​​in the same fields during reconciliation.

[0209] Similarly, when merging the deduction results of multiple transactions, multiple deduction merging tasks can also be generated, and the multiple deduction merging tasks can be handed over to one or more instances for processing. Each deduction merging task is used to merge multiple deduction results in a merge group to obtain the corresponding merged deduction result. It should be noted that the division granularity of the deduction merging task is consistent with the division granularity of the billing merging task, that is, a deduction merging task can correspond to a billing merging task. The multiple transactions processed by the deduction merging task and the multiple transactions processed by the corresponding billing merging task are the same group of transactions. The billing merging task merges the billing results of this group of transactions, and the deduction merging task merges the deduction results of this group of transactions. The division and processing of the deduction merging task can refer to the division and processing methods of the aforementioned billing merging task, such as microservice architecture and sharding flow technology, or based on the big data platform, which will not be repeated here.

[0210] It should be noted that each generated combined deduction result can correspond to a deduction bitmap, and the description of the deduction bitmap is similar to the description of the billing bitmap. In addition, the reconciliation system 400 will establish a mapping relationship between the combined deduction results and the combined accounting results, and a mapping relationship will be established between the combined deduction results and the combined accounting results of a combined group.

[0211] S206: The reconciliation system 400 determines whether the difference between the combined billing result and the combined deduction result is greater than a warning threshold. This step can be implemented by the reconciliation unit 460 in the embodiment of FIG1 .

[0212] In the specific implementation, the difference between the combined billing result and the combined deduction result can be one or more, and each difference can correspond to the difference in the handling fees of a category in the combined billing result and the combined deduction result, such as the difference in the total amount of channel costs, the difference in the total amount of clearing fees, the difference in the total amount of settlement fees, the difference in the total amount of network fees, etc. The number of warning thresholds can also be one or more, and the difference in the handling fees of a category corresponds to a warning threshold, such as the warning threshold of the total amount of channel costs is used to determine whether the difference in the total amount of channel costs exceeds the limit, and the warning threshold of the total amount of clearing fees is used to determine whether the difference in the total amount of clearing fees exceeds the limit, etc. This application does not make specific limitations.

[0213] Optionally, if the difference is not greater than the warning threshold, execute S207; if the difference is greater than the warning threshold, execute S208 and S209. It should be understood that if the difference is not greater than the warning threshold, it means that the combined billing results and the combined deduction results of multiple transactions in a combined group are very close. For multiple transactions, a very small difference has little impact on the overall financial situation and can be ignored. For example, if the combined billing result and the combined deduction result of 1,000 transactions differ by 1 cent, then checking each account to determine the difference of 1 cent is very labor-intensive and resource-intensive. This application can directly write off multiple orders with small differences by combining and reconciling, thereby improving the efficiency of channel cost reconciliation.

[0214] It should be noted that if there are multiple difference values ​​and multiple warning thresholds, it is possible to determine whether the difference between the combined billing result and the combined deduction result is higher than the warning threshold based on the comparison results of the multiple difference values ​​with the corresponding warning thresholds. For example, when more than three difference values ​​exceed their corresponding warning thresholds, it is determined that the difference between the combined billing result and the combined deduction result is higher than the warning threshold. Of course, other rules can also be used to determine whether the difference between the combined billing result and the combined deduction result is higher than the warning threshold based on the comparison results of multiple difference values ​​with the corresponding warning thresholds. This application does not limit this rule.

[0215] S207: The reconciliation system 400 performs a write-off operation on the channel costs of the multiple transactions. This step can be implemented by the analysis unit 470 in the embodiment of FIG1 .

[0216] It should be understood that the description of the write-off operation can refer to the above content and will not be repeated here.

[0217] S208: The reconciliation system 400 sends an early warning message to the client 100. This step can be implemented by the analysis unit 470 in the embodiment of FIG1.

[0218] In a specific implementation, the warning information may include the above-mentioned multiple differences, and may also include some other information for the management user to locate and analyze the reasons for the differences. For example, other information may include reconciliation time, transaction status, difference details, etc. Among them, the difference details may include the transaction data of the transaction with the difference, and information on which specific part of the transaction fee cannot be reconciled, so that the management user can locate the reason for the reconciliation failure.

[0219] In a specific implementation, when determining the difference details, the billing result and deduction result of each transaction can be read through the billing bitmap and deduction bitmap, and then the billing result of each transaction can be compared with the deduction result to determine the transactions with differences. Then, for each transaction with differences, the billing and deduction of each handling fee can be further checked to see if they are consistent, so as to determine which handling fee of which transaction cannot be reconciled, and generate difference details for the management user to locate the cause of the reconciliation failure. The above examples are for illustration purposes only, and this application does not limit the specific content of the difference details.

[0220] S209: The client 100 sends a request to modify the billing model to the reconciliation system 400. This step can be implemented by the configuration unit 410 in the embodiment of FIG1.

[0221] It is understandable that after the management user obtains the early warning information through the client 100, he can locate the reason for the reconciliation failure based on the difference details in the early warning information, and then adjust the billing model, update the billing bitmap and the detailed table corresponding to the billing bitmap, obtain the information merge accounting result, and reconcile the merged accounting result with the merged deduction result. If the difference is lower than the threshold, it will be written off. If the difference is still higher than the threshold, the management personnel will need to readjust the billing model. It should be understood that in this method, the user only needs to query the account and then locate the reason for the reconciliation failure and adjust the billing model. There is no need to adjust thousands of inconsistent accounts. Adjustment is a very complicated step and is very dependent on manual operation. The reconciliation method provided by this application does not require adjustment. The entire reconciliation process can be automated. The management personnel only need to analyze and locate the reason for the reconciliation failure and adjust the billing model, which greatly reduces the pressure of manual processing and improves the work efficiency of the management personnel.

[0222] To facilitate a better understanding of the present application, the beneficial effects of the reconciliation method provided herein are described in detail below with reference to FIG7 . FIG7 is an example diagram of a channel cost reconciliation interface provided herein. This interface may be displayed to the user after S203 to S208 are executed after the management user configures the billing model through the interface shown in FIG3 and the reconciliation system 400 begins reconciling channel costs according to the billing model. As shown in FIG7 , this interface may include a query area 710 , a toolbar 720 , and a reconciliation result display area 730 .

[0223] Query area 710 is used to enter the query attributes to be queried, such as the channel product name, channel name, and transaction time shown in Figure 7. After the user clicks the query, the reconciliation result display area 730 below can display data that meets the query attributes. The query attributes entered can be any of the aforementioned attributes, such as the consolidated billing attributes, transaction attributes, billing attributes, and deduction attributes, and this application does not specifically limit them.

[0224] Toolbar 720 includes multiple controls. FIG7 exemplifies several possible controls, such as an early warning control, an analysis control, a reconciliation control, a write-off control, a model modification control, and a recount control. The early warning control is used to send early warning information to the user. In the example shown in FIG7 , the early warning information may include a difference and a number of difference transactions. The difference and the number of difference transactions of the consolidated group to be analyzed are marked in dark color. The user can quickly locate the difference to be processed by the dark color mark in the reconciliation result display area 730. The analysis control is used to query the difference details of the consolidated group whose difference exceeds the early warning threshold. The reconciliation control is used to start channel cost reconciliation, causing the reconciliation system 400 to start executing S202A to S209. The write-off control is used to instruct the reconciliation system 400 to start executing S207 and perform channel cost write-off processing on multiple transactions in the consolidated group whose difference is below the early warning threshold. The model modification control is used for the management user to modify the configuration parameters of the billing model. The recount control is used for the management user to update the consolidated billing results, difference, number of difference transactions, and other information using the new billing model after modifying the configuration parameters of the billing model. It should be understood that the toolbar 720 can also be configured with more controls according to usage requirements, and this application does not make specific limitations.

[0225] The reconciliation result display area 730 is used to display the reconciliation results and warning information.

[0226] In the example shown in Figure 7, the combined groups of Sequences 1 and 5 both have discrepancies, meaning the combined billing results differ from the combined deduction results. Assuming the warning threshold is 1 yuan, the difference in the combined group of Sequence 5 is only 0.01 yuan, which is below the warning threshold and can be written off along with the other combined groups without discrepancies. However, the difference in the combined group of Sequence 1 far exceeds the warning threshold. The administrator needs to analyze and locate the cause of the discrepancy, modify the billing model parameters, and recalculate the combined billing results until the combined group of Sequence 1 can also complete the write-off.

[0227] It should be understood that the management user can modify the configuration parameters of the billing model through the Modify Model control in the toolbar 720. For example, after the management user clicks the Modify Model control, the client 100 can display the interface shown in Figure 3 to the management user. After the user locates the cause of the difference, such as determining that the bank temporarily lowers the handling fee, the amount of the bank handling fee in the billing rules can be modified at this time, and then return to the interface shown in Figure 7 and click the Re-billing control.

[0228] It should be understood that through the interface shown in Figure 7, users can intuitively and quickly learn about multiple transactions that have failed to be reconciled, without having to check the accounts one by one; and, if the anomalies of a group of accounts are the same, users can locate and analyze the causes of the anomalies in batches, thereby improving processing efficiency; at the same time, after the user determines the cause of the analysis, there is no need to adjust the accounts one by one, and the billing model parameters can be modified. The entire process is very simple and fast, which improves the user experience.

[0229] In summary, the present application provides a reconciliation method, which can obtain transaction data of multiple transactions from a payment channel system, determine the billing result of the payment channel cost of each transaction based on a billing model, and then obtain the deduction result of the payment channel cost of each transaction from a bank system, and then merge the billing results of multiple transactions to obtain a merged billing result, merge the deduction results of multiple transactions to obtain a merged deduction result, determine the difference between the merged billing result and the merged deduction result, and when the difference exceeds the warning threshold, send a warning message to the management user to instruct the user to update the billing model, so that the channel cost can be reconciled in a merged reconciliation, without the need to reconcile one by one, thereby improving the reconciliation efficiency. At the same time, the management user can update the billing model according to the warning information, and no longer need to adjust the account one by one, thereby improving the reconciliation efficiency, reducing labor costs, and improving the user experience.

[0230] The above describes in detail the reconciliation system and reconciliation method provided by the present application. The computing device provided by the present application is explained below in conjunction with Figure 8.

[0231] Figure 8 is a schematic diagram of the structure of a computing device provided in this application. The computing device 800 may be the reconciliation system described above. Furthermore, the computing device 800 includes a processor 801, a storage unit 802, a storage medium 803, and a communication interface 804. The processor 801, storage unit 802, storage medium 803, and communication interface 804 communicate via a bus 805, and may also communicate via other means such as wireless transmission.

[0232] The processor 801 is composed of multiple general-purpose processors, such as CPUs. The hardware chip is an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD is a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), a data processing unit (DPU), a system on chip (SoC), or any combination thereof. The processor 801 executes various types of digital storage instructions, such as software or firmware programs stored in the storage unit 802, which enables the computing device 800 to provide a wide variety of services.

[0233] In a specific implementation, as an embodiment, the processor 801 includes one or more CPUs, such as CPU0 and CPU1 shown in FIG8 .

[0234] In a specific implementation, as an embodiment, the computing device 800 also includes multiple processors, such as processor 801 and processor 806 shown in FIG8 . Each of these processors can be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). A processor here refers to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0235] The storage unit 802 is used to store program code, and is controlled by the processor 801 to execute the processing steps of the reconciliation system in any of the embodiments of Figures 1 to 7 above. The program code includes one or more software units. The above-mentioned one or more software units are the single billing unit, the first merging unit, the receiving unit, the second merging unit, the reconciliation unit and the analysis unit in the embodiment of Figure 1, wherein the single billing unit is used to obtain the transaction data of multiple transactions from the payment channel system, and determine the billing result of the payment channel cost of each transaction based on the billing model, specifically for executing S202A, S203 and its optional steps in the embodiment of Figure 2; the first merging unit is used to merge the billing results of multiple transactions to obtain a combined billing result, specifically for executing S205 and its optional steps in the embodiment of Figure 2; the receiving unit is used to obtain the deduction result of the payment channel cost of each transaction from the bank system, specifically for executing S204 and its optional steps in the embodiment of Figure 2 Optional steps; a second merging unit, used to merge the deduction results of multiple transactions in each merged group to obtain the deduction results of each merged group, and then obtain the merged billing results of multiple transactions, specifically used to execute S205 and its optional steps in the embodiment of Figure 2; a reconciliation unit, used to determine the difference between the merged billing result and the merged deduction result, specifically used to execute S206 and its optional steps in the embodiment of Figure 2; an analysis unit, used to send an early warning message to the user when the difference exceeds the early warning threshold, the early warning message is used to instruct the user to update the billing model, and perform channel cost write-off operations on multiple transactions when the difference does not exceed the early warning threshold, specifically used to execute S207~S209 and its optional steps in the embodiment of Figure 2.

[0236] The storage unit 802 includes a read-only memory and a random access memory, and provides instructions and data to the processor 801. The storage unit 802 also includes a non-volatile random access memory. The storage unit 802 is a volatile memory or a non-volatile memory, or includes both volatile and non-volatile memories. Among them, the non-volatile memory is a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), or a flash memory. The volatile memory is a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are used, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronized dynamic random access memory (SLDRAM), and direct RAM bus RAM (DR RAM). A hard disk, a universal serial bus (USB), a flash memory, a secure digital memory card (SD card), a memory stick, etc., and a hard disk can be a hard disk drive (HDD), a solid state drive (SSD), a mechanical hard disk (HDD), etc., which is not specifically limited in this application.

[0237] The storage medium 803 is a carrier for storing data, such as a hard disk, a universal serial bus (USB), a flash memory, a secure digital memory card (SD card), a memory stick, etc. The hard disk can be a hard disk drive (HDD), a solid state disk (SSD), a mechanical hard disk (HDD), etc., and this application does not make specific limitations.

[0238] The communication interface 804 is a wired interface (such as an Ethernet interface), an internal interface (such as a high-speed serial computer expansion bus (Peripheral Component Interconnect express, PCIe) bus interface), a wired interface (such as an Ethernet interface) or a wireless interface (such as a cellular network interface or a wireless local area network interface) used to communicate with other servers or units.

[0239] Bus 805 is a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a unified bus (UBus or UB), a Compute Express Link (CXL), or a Cache Coherent Interconnect for Accelerators (CCIX). Bus 805 is divided into an address bus, a data bus, and a control bus.

[0240] In addition to the data bus, the bus 805 also includes a power bus, a control bus, a status signal bus, etc. However, for the sake of clarity, various buses are labeled as the bus 805 in the figure.

[0241] It should be noted that FIG8 is only one possible implementation of the embodiment of the present application. In actual applications, the computing device 800 may also include more or fewer components, which is not limited here. For matters not shown or described in the embodiment of the present application, please refer to the relevant description in the embodiments of FIG1 to FIG7 above, and will not be repeated here.

[0242] The present application also provides a computing device cluster, which may be the reconciliation system described above, and includes at least one computing device 800. The storage unit 802 in one or more computing devices 800 in the computing device cluster may store the same or different instructions for executing the reconciliation method.

[0243] Embodiments of the present application also provide a computer program product containing instructions. The computer program product may be software or a program product containing instructions that can be executed on a computing device or stored on any available medium. When the computer program product is executed on at least one computing device, the at least one computing device executes a reconciliation method.

[0244] Embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device, or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a high-density digital video disc (DVD)), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the reconciliation method.

[0245] The above embodiments can be implemented in whole or in part through software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. A computer program product includes multiple computer instructions. When the computer program instructions are loaded or executed on a computer, the processes or functions according to the embodiments of the present invention are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0246] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent repairs or replacements within the technical scope disclosed in the present invention, and such repairs or replacements should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A reconciliation method, characterized in that: The method is applied to a reconciliation system, and includes: Acquire transaction data of multiple transactions from the payment channel system and determine the billing result of the payment channel cost for each transaction based on a billing model. The billing model includes billing elements and corresponding billing rules. The billing elements are used to determine the billing rules used when billing the channel cost for the transaction data. The correspondence between the billing elements and the billing rules is configured by the user through a visual interface. Obtain the deduction results of the payment channel cost for each transaction from the banking system; Combining the billing results of the multiple transactions to obtain a combined billing result, and combining the deduction results of the multiple transactions to obtain a combined deduction result; Determining the difference between the combined billing result and the combined deduction result; When the difference exceeds the warning threshold, a warning message is sent to the user, where the warning message is used to instruct the user to update the billing model.

2. The method according to claim 1, characterized in that The method further comprises: When the difference does not exceed the warning threshold, a channel cost write-off operation is performed on the multiple transactions.

3. The method according to claim 1 or 2, characterized in that The billing result of obtaining transaction data of multiple transactions and determining the payment channel cost of each transaction based on the billing model includes: Acquire transaction data of a plurality of transactions and determine a plurality of transaction attributes of each transaction, wherein the transaction attributes are used to describe the transaction data; Generate a transaction attribute table based on multiple transaction attributes of each transaction. The transaction attribute table includes multiple fields, each field represents a transaction attribute, and each row of data in the transaction attribute table corresponds to a batch of transaction data with multiple identical transaction attributes. Determine the billing model corresponding to each batch of transaction data based on transaction attributes; According to the billing model corresponding to each batch of transaction data, the billing result of the channel cost corresponding to each transaction data in each batch of transaction data is determined.

4. The method according to any one of claims 1 to 3, characterized in that The reconciliation system includes multiple billing bitmaps, wherein one billing result corresponds to one billing bitmap, the billing bitmap includes multiple bits, each bit corresponds to a billing attribute, the value of each bit is used to indicate whether the corresponding billing attribute exists in the corresponding billing result, and the billing attribute is used to describe the billing result.

5. The method according to claim 4, characterized in that Combining the billing results of the multiple transactions to obtain a combined billing result includes: Obtain one or more combined billing attributes, and group the multiple transactions into multiple combined groups based on the one or more combined billing attributes and the multiple billing bitmaps, wherein multiple transactions in a combined group include the same combined billing attributes; Merge the billing results of multiple transactions in each merge group to obtain the billing result of each merge group; According to the billing result of each combined group, a combined billing result of the multiple transactions is obtained.

6. The method according to claim 5, characterized in that The dividing the plurality of transactions into a plurality of combined groups based on the one or more combined billing attributes and the plurality of billing bitmaps comprises: determining one or more masks according to the one or more combined charging attributes; Applying the one or more masks to the multiple charging bitmaps to obtain multiple merged groups containing the one or more merged charging attributes.

7. The method according to claim 5 or 6, characterized in that Merging the billing results of multiple transactions in each merged group to obtain the merged result of each merged group includes: Send multiple single billing results of multiple transactions in each merged group to different instances for processing to obtain a merged result completed by each instance, wherein the instance includes a physical machine, a virtual machine or a container, and the number of transactions in each merged group is determined according to the processing capacity of each instance.

8. The method according to any one of claims 5 to 7, characterized in that: Combining the deduction results of the multiple transactions to obtain a combined deduction result includes: Merge the deduction results of multiple transactions in each merge group to obtain the deduction result of each merge group; Obtaining a combined billing result for the multiple transactions based on the deduction result of each combined group; Determining the difference between the combined billing result and the combined deduction result includes: Determine the difference between the chargeback results and the billing results for each merged group.

9. A reconciliation system, characterized in that: The system comprises: A single-transaction billing unit is used to obtain transaction data of multiple transactions from the payment channel system and determine the billing result of the payment channel cost for each transaction based on a billing model. The billing model includes billing elements and corresponding billing rules. The billing elements are used to determine the billing rules used when billing the channel cost of the transaction data. The correspondence between the billing elements and the billing rules is configured by the user through a visual interface. A receiving unit, used to obtain the deduction result of the payment channel cost of each transaction from the banking system; a first merging unit, configured to merge the billing results of the multiple transactions to obtain a merged billing result; and a second merging unit, configured to merge the deduction results of the multiple transactions to obtain a merged deduction result; a reconciliation unit, configured to determine a difference between the combined billing result and the combined deduction result; The analyzing unit is configured to send a warning message to the user when the difference exceeds a warning threshold, wherein the warning message is used to instruct the user to update the billing model.

10. The system according to claim 9, characterized in that The analyzing unit is configured to, when the difference does not exceed the warning threshold, perform a write-off operation on the channel costs of the multiple transactions.

11. The system according to claim 9 or 10, characterized in that The single transaction billing unit is used to obtain transaction data of multiple transactions and determine multiple transaction attributes of each transaction, where the transaction attributes are used to describe the transaction data; The single-transaction billing unit is configured to generate a transaction attribute table based on multiple transaction attributes of each transaction, wherein the transaction attribute table includes multiple fields, each field representing a transaction attribute, and each row of data in the transaction attribute table corresponds to a batch of transaction data having multiple identical transaction attributes; The single transaction billing unit is used to determine the billing model corresponding to each batch of transaction data according to the transaction attributes; The single transaction billing unit is used to determine the billing result of the channel cost corresponding to each transaction data in each batch of transaction data according to the billing model corresponding to each batch of transaction data.

12. The system according to any one of claims 9 to 11, characterized in that: The reconciliation system includes multiple billing bitmaps, wherein one billing result corresponds to one billing bitmap, the billing bitmap includes multiple bits, each bit corresponds to a billing attribute, the value of each bit is used to indicate whether the corresponding billing attribute exists in the corresponding billing result, and the billing attribute is used to describe the billing result.

13. The system according to claim 12, wherein: The first merging unit is configured to obtain one or more combined billing attributes, and group the multiple transactions into multiple combined groups based on the one or more combined billing attributes and the multiple billing bitmaps, wherein multiple transactions in a combined group include the same combined billing attribute; The first merging unit is configured to merge the billing results of multiple transactions in each merged group to obtain a billing result for each merged group; The first merging unit is configured to obtain a combined billing result of the multiple transactions based on the billing result of each combined group.

14. The system according to claim 13, wherein: The first merging unit is configured to determine one or more masks according to the one or more combined charging attributes; The first merging unit is configured to apply the one or more masks to the multiple charging bitmaps to obtain multiple merged groups containing the one or more merged charging attributes.

15. The system according to claim 13 or 14, characterized in that The first merging unit is used to send multiple single billing results of multiple transactions in each merged group to different instances for processing, so as to obtain a merged result completed by each instance, wherein the instance includes a physical machine, a virtual machine or a container, and the number of transactions in each merged group is determined according to the processing capacity of each instance.

16. The system according to any one of claims 13 to 15, characterized in that The second merging unit is configured to merge the deduction results of multiple transactions in each merged group to obtain the deduction result of each merged group; The second merging unit is configured to obtain a combined billing result of the multiple transactions based on the deduction result of each combined group; The reconciliation unit is used to determine the difference between the deduction result and the billing result of each merged group.

17. A computing device, characterized in that The computing device includes a processor and a memory, wherein the memory is used to store instructions, and the processor is used to execute the instructions, so that the computing device implements the method according to any one of claims 1 to 8.

18. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, and when the instructions are executed by a computing device or a computing device cluster, the method according to any one of claims 1 to 8 is implemented.

Images