Financial automation method and system based on cross-platform industry and financial data aggregation and AI intelligent accounting

Abstract

The application provides a financial automation method and system based on cross-platform industry and financial data aggregation and AI intelligent accounting, relates to the technical field of enterprise financial management, and first acquires original business event streams of a plurality of external business platform data sources and a static financial rule information set of an enterprise internal resource planning system, carries out associated clue mining and cross-event aggregation on the original business event streams to generate a fusion transaction matter description structure body, then calls an accounting rule matcher to disassemble accounting elements and map and bind to generate a multi-dimensional accounting instruction set, and finally merges and processes the multi-dimensional accounting instruction set to generate a total account updating instruction stream, injects the enterprise internal resource planning system to drive account synchronization updating, and realizes financial automation accounting.

Description

Technical Field

[0001] This invention relates to the field of enterprise financial management technology, and more specifically, to a financial automation method and system based on cross-platform business and financial data aggregation and AI intelligent accounting. Background Technology

[0002] With the acceleration of digitalization, enterprise transactions are becoming increasingly complex and dispersed across multiple external business platforms, while enterprises also have independent resource planning systems. Traditional financial accounting methods face numerous challenges. On the one hand, the numerous external business platforms, each outputting business data in different formats and with varying content, make it difficult for enterprises to directly obtain unified and complete business information. For example, order status change records from different e-commerce platforms, invoice status change records from logistics platforms, and fund transfer status change records from payment platforms are independent and lack effective correlation. This forces finance personnel to spend a significant amount of time and effort collecting and organizing this scattered data, resulting in low efficiency and a high risk of errors. On the other hand, static financial rules information in the enterprise's internal resource planning system, such as chart of accounts structure information and tax processing rules information, lacks an effective integration mechanism with external business data. Existing financial automation methods often fail to accurately match and intelligently account for external business events with internal financial rules, making it difficult to achieve automated processing of financial data and real-time updates of accounts, thus failing to meet the requirements of efficient and accurate financial management for modern enterprises. Summary of the Invention

[0003] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting, the method comprising:

[0004] The system acquires raw business event streams from multiple external business platform data sources associated with the enterprise's transaction activities, as well as a set of static financial rule information extracted from the enterprise's internal resource planning system. The raw business event streams include order status change events, invoice status change events, and fund transfer status change events. The set of static financial rule information includes accounting chart structure information and tax processing rule information.

[0005] The order status change events, bill status change events, and fund transfer status change events in the original business event flow are processed to mine the inter-event correlation clues. Based on the mined correlation clues, the order status change events, bill status change events, and fund transfer status change events belonging to the same transaction context are aggregated across events to generate a fused transaction description structure.

[0006] The embedded accounting rule matcher is invoked to decompose the accounting elements of the integrated transaction description structure. The revenue recognition element group, cost collection element group, tax calculation element group, and accounts receivable / payable tracking element group are separated from the integrated transaction description structure in sequence. Each separated element group is then mapped and bound to the accounting subject table structure information and tax processing rule information in the static financial rule information set to generate a multi-dimensional accounting instruction set corresponding to the integrated transaction description structure.

[0007] The accounting direction indication information and account hierarchy path information carried in the multi-dimensional accounting instruction set are processed by instruction merging to generate a general ledger update instruction stream containing general ledger account summary information and subsidiary ledger account occurrence information. The general ledger update instruction stream is then injected into the general ledger processing module of the enterprise's internal resource planning system to drive the synchronous update operation of the general ledger and subsidiary ledger.

[0008] Furthermore, embodiments of the present invention also provide a financial automation system based on cross-platform business and financial data aggregation and AI intelligent accounting, comprising:

[0009] A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the aforementioned financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting by executing the machine-executable instructions.

[0010] In another aspect, embodiments of the present invention also provide a computer program product, the computer program product including machine-executable instructions stored in a computer-readable storage medium, a processor of a financial automation system based on cross-platform business and financial data aggregation and AI intelligent accounting reading the machine-executable instructions from the computer-readable storage medium, the processor executing the machine-executable instructions, causing the financial automation system based on cross-platform business and financial data aggregation and AI intelligent accounting to execute the aforementioned financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting.

[0011] Based on the above, by acquiring raw business event streams from multiple external business platform data sources and static financial rule information sets from the enterprise's internal resource planning system, the system performs inter-event correlation mining and cross-event aggregation on the raw business event streams to generate a fused transaction description structure. This effectively solves the problem of scattered and unrelated external business data. The embedded accounting rule matcher is then used to decompose and map the accounting elements of the fused transaction description structure, generating a multi-dimensional accounting instruction set. This achieves intelligent conversion of business data into financial accounting elements, improving the accuracy and efficiency of accounting. The multi-dimensional accounting instruction set is then merged to generate a general ledger update instruction stream, which is injected into the enterprise's internal resource planning system. This drives the synchronous update of the general ledger and subsidiary ledgers, achieving automated processing of financial data and real-time updates of accounts, significantly improving the efficiency and accuracy of enterprise financial management. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the execution flow of the financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting provided in an embodiment of the present invention.

[0013] Figure 2 This is a schematic diagram of exemplary hardware and software components of a financial automation system based on cross-platform business and financial data aggregation and AI intelligent accounting, provided in an embodiment of the present invention. Detailed Implementation

[0014] Figure 1 This is a flowchart illustrating a financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting, provided in one embodiment of the present invention. It will be described in detail below.

[0015] Step S110: Obtain the original business event streams output from multiple external business platform data sources associated with the enterprise's transaction activities, as well as the set of static financial rule information extracted from the enterprise's internal resource planning system.

[0016] First, communication connections are established with multiple external business platform data sources to continuously receive raw business event streams. Simultaneously, static rule information is extracted from the enterprise's internal resource planning system database to guide subsequent financial processing.

[0017] Step S111: Access the order status change push service provided by the e-commerce transaction platform data source. Subscribe to the order status change topics published by the e-commerce transaction platform data source through the order status change push service. Pull order status change events in real time from the order status change topics. The event body of each order status change event encapsulates the globally unique identifier string of the order, the order status change path description string, the unit code set of the inventory quantity of the traded goods, the set of the quantity of goods traded, the set of the unit price of goods traded, the buyer member identifier string, the seller store identifier string, and the total amount of the order including tax.

[0018] Specifically, connection requests are initiated to the platform application programming interfaces (APIs) exposed to the data sources of various e-commerce transaction platforms. For example, subscription requests can be initiated to the order status change notification topics published by each platform by calling the order service interface functions provided by each platform, carrying the necessary authentication tokens. After establishing a persistent transport layer secure connection, when an order status changes on any external e-commerce transaction platform, such as a change in order status from PAY_PENDING to PAY_SUCCESS after a consumer places an order, or from DELIVERED to TRADE_FINISHED, the platform's message routing middleware will encapsulate this status change into an event body consisting of an ordered set of key-value pairs and push it to all subscribed aggregation servers according to the publish-subscribe protocol. The event body of each pushed order status change event is constructed as a lightweight data exchange format document containing multiple data fields. This document encapsulates all key information related to the order, specifically including: a globally unique identifier string for the order across the entire network, denoted as the Order Globally Unique Identifier String O_GUID; a sequence of status code values ​​connected by a specific delimiter, used to describe the complete path of order status changes, denoted as the Order Status Transition Path Description String O_StatusPath; a list-type array consisting of one or more product inventory unit codes involved in this transaction, denoted as the Transaction Product Inventory Unit Code Set SKU_Set; and an integer array consisting of the quantity of goods sold corresponding to each element in the SKU_Set array at its index position. The order is represented by: Qty_Set (the set of the number of transactions); Price_Set (a floating-point array representing the unit price of each transaction, corresponding to each element in SKU_Set at its index); Buyer_ID (a unique identifier string for the buyer on the external platform); Seller_ID (a unique identifier string for the seller on the external platform); and Ord_Amt_Tax (a long integer value stored in cents, representing the total amount including VAT and other taxes).

[0019] Step S112: Access the invoice status change push service provided by the electronic invoice service platform data source, subscribe to the invoice status change topics published by the electronic invoice service platform data source through the invoice status change push service, and pull invoice status change events in real time from the invoice status change topics. The event body of each invoice status change event encapsulates the globally unique invoice identifier string, invoice type descriptor, invoice tax amount value, seller taxpayer identification number string, buyer taxpayer identification number string, and the globally unique order identifier string set associated with the globally unique invoice identifier string.

[0020] Next, the data aggregation server connects to the data sources of various e-invoice service platforms using the same connection and subscription method. The server sends subscription requests to the message middleware of each e-invoice service platform, subscribing to their published invoice status change topics. When an enterprise needs to issue invoices for orders placed on external e-commerce platforms, the internal resource planning system or e-commerce system requests and calls the invoicing interface of the e-invoice service platform via Hypertext Transfer Protocol. After the invoice is verified by the tax bureau system and an anti-counterfeiting code is generated, the message queue product of the e-invoice service platform generates an invoice status transition event and asynchronously pushes it to the subscribed servers. The data exchange format document contained in the event body of each invoice status transition event encapsulates the following information: a string consisting of an invoice code and invoice number that uniquely identifies the invoice nationwide, denoted as the globally unique invoice identifier string I_GUID; an enumerated value describing the invoice type, for example, a value of INV_SPECIAL indicates a VAT special invoice, and a value of INV_NORMAL indicates a VAT ordinary invoice, denoted as the invoice type descriptor I_Type; and the tax amount stated on the invoice, a long integer value stored in cents, denoted as the invoice tax amount value I_Tax_. Amt; the unified social credit code string of the seller company registered with the tax bureau, denoted as Seller_TaxID; the unified social credit code or personal identification number string of the buyer company, denoted as Buyer_TaxID; and a list array consisting of one or more globally unique identifier strings associated with the invoice, denoted as Ref_O_GUID_Set. For the common case of issuing one invoice for one order, this array contains one element, namely O_GUID.

[0021] Step S113: Access the fund transfer status change push service provided by the bank payment and settlement platform data source. Subscribe to the fund transfer status change topics published by the bank payment and settlement platform data source through the fund transfer status change push service. Pull fund transfer status change events in real time from the fund transfer status change topics. The event body of each fund transfer status change event encapsulates the fund transfer transaction serial number string, the payer's bank account string, the payee's bank account string, the fund transfer amount, the fund transfer completion timestamp, the fund transfer status descriptor, and the globally unique identifier string of the order or the globally unique identifier string of the invoice associated with the fund transfer behavior.

[0022] Then, the data aggregation server connects to the enterprise-level fund notification interfaces provided by the data sources of various bank payment and settlement platforms. The server registers with the message queues or Hypertext Transfer Protocol callback interfaces of each bank to listen for and subscribe to fund transfer status change topics published by the bank system. When a consumer completes a payment using online banking on an external e-commerce platform, or when a company pays a supplier through the bank-enterprise direct connection system, the bank's core accounting system completes the fund clearing and encapsulates the final status of the fund transfer into a standard format financial interaction protocol data packet, which is then pushed to the registered server address. The data exchange format document contained in the event body of each fund transfer status change event encapsulates the following information: a globally unique serial number string generated by the bank's core system for the transaction, denoted as the fund transfer transaction serial number string F_SerialNo; the payer's RMB bank settlement account string, denoted as the payer's bank account string Payyer_Acct; the payee's RMB bank settlement account string, denoted as the payee's bank account string Payee_Acct; the actual amount transferred from the payer's account to the payee's account, stored as a long integer value in milliseconds, denoted as the fund transfer amount value F_Amt; and the host time of transaction completion recorded by the bank's core system, expressed as a timestamp in milliseconds. The value is denoted as the timestamp for fund transfer completion, F_Timestamp; the enumerated value describing the result of fund transfer, for example, a value of TRANSFER_SUCCESS indicates a successful transfer, and a value of TRANSFER_FAILED indicates a failed transfer, denoted as the fund transfer status descriptor F_Status; and the business document identifier associated with this fund transfer, most commonly the merchant order number carried in the payment callback interface, i.e., the globally unique identifier string O_GUID of the order. If it is only for discounting or factoring payments for invoices, it may also be the associated globally unique identifier string I_GUID of the invoice. This field is denoted as the associated globally unique identifier string of the order or the globally unique identifier string of the invoice, Ref_O_or_I_GUID.

[0023] Step S114: Write the real-time retrieved order status change events, invoice status change events, and fund transfer status change events into different topic storage partitions of the distributed message queue system in the order of their occurrence timestamps, forming a continuously flowing stream of original business events.

[0024] Upon receiving the three types of events mentioned above, the data aggregation server does not immediately initiate complex business logic processing. Instead, it first performs data distribution and cache persistence. The server parses the event occurrence timestamp field encapsulated in the data exchange format document of each event body. For example, for order events, the order creation time can be used, and for fund events, the fund transfer completion timestamp F_Timestamp can be used. Then, the server, acting as a producer client, uses the software development kit provided by the distributed message queue system to establish connections with the message cluster according to the event type. It writes the producer messages for order status transition events, in ascending order of event occurrence timestamps, into a specific logical storage partition named "Original Order Event Subject"; the producer messages for invoice status transition events, into a specific logical storage partition named "Original Invoice Event Subject"; and the producer messages for fund transfer status transition events, into a specific logical storage partition named "Original Fund Event Subject". Through this topic-based isolated storage mechanism, the continuous high-speed influx of raw events from multiple heterogeneous data sources is organized into an orderly stream of raw business events that can be consumed independently, stably, and reliably by multiple downstream processing units at different rates.

[0025] Step S115: Read the pre-configured subject structure tree table from the database of the enterprise's internal resource planning system. The subject structure tree table includes a subject code primary key field, a subject full Chinese name field, a subject level numeric field, a parent subject code field, a subject category distinction field, and a subject balance direction indicator field. Use the read subject structure tree table as the accounting subject table structure information.

[0026] In addition to the aforementioned access and caching of dynamic event streams, this method also needs to extract static structured rule information from the enterprise's internal resource planning system database. The data reading service connects to and queries the subject structure tree table in the internal resource planning system's backend relational database via an open database connection or Java database connection interface. This subject structure tree table stores the hierarchical definition of the enterprise's complete accounting subject system in a relational model format. Each row in the table represents a specific accounting subject and contains several fixed field definitions: a primary key field for the subject code that uniquely identifies the row in the relational database, containing a string representing the subject code in accordance with accounting standards; a field for the full Chinese name of the subject displayed in the financial report, containing a string; an integer field indicating the subject's level depth in the tree structure, for example, a first-level subject is stored as an integer 1, a second-level subject as an integer 2, denoted as the subject level number field; a parent subject code field that records the primary key field value of the subject code of its direct superior subject, which is stored as a null value or an empty string for first-level subjects; a subject category field that distinguishes the economic nature of the subject, containing an enumerated value, for example, ASSET for assets, LIABILITY for liabilities, EQUITY for equity, COST for costs, and P_L for profit and loss; and a subject balance direction indicator field that indicates the default direction of the subject balance, i.e., debit or credit, containing an enumerated value, for example, DEBIT for debit balance and CREDIT for credit balance. All rows retrieved from this table will be loaded as a collection of in-memory objects, which will serve as the overall chart of accounts structure information.

[0027] Step S116: Read the pre-configured tax jurisdiction area table from the database of the enterprise's internal resource planning system. The tax jurisdiction area table includes a tax jurisdiction area code field, a jurisdiction area name field, an applicable tax rate value field, a tax base definition text field, and a tax liability occurrence time determination rule text field. Use the read tax jurisdiction area table as tax processing rule information.

[0028] Simultaneously, the data retrieval service also connects to and queries the tax jurisdiction area table in the internal resource planning system's backend relational database via open database connections or Java database connection interfaces. This tax jurisdiction area table stores the tax policies and rules applicable to enterprises operating in different regions. Each row in the table represents a specific tax jurisdiction and contains several field definitions: a tax jurisdiction area code field, a string, for example, CN_BJ_ZS representing value-added tax in Beijing, China; the natural language name of the jurisdiction, a string; the applicable statutory tax rate, a floating-point number stored as a percentage, for example, 13% stored as 13.0, a variable-point number; rule text describing how the tax base is calculated, such as "sales amount excluding tax," a variable-point text field; and the judgment logic describing when tax liability is triggered, such as "the day the goods are shipped" or "the day payment is received," a variable-point text field. All rows retrieved from this table are loaded as a collection of in-memory objects, serving as the overall tax processing rule information.

[0029] Step S120: Perform inter-event correlation mining on the order status change events, bill status change events, and fund transfer status change events in the original business event flow. Based on the mined correlation clues, perform cross-event aggregation on the order status change events, bill status change events, and fund transfer status change events belonging to the same transaction context to generate a fused transaction description structure.

[0030] After completing the access and caching of the original business event stream and the extraction of static rule information, the next core task is to identify and aggregate various events that belong to the same complete transaction but are scattered across different themes, and to reconstruct the full picture of the transaction.

[0031] Step S121: Pull order status transition events sequentially from the order status transition topic storage partition of the distributed message queue system, parse the event body of the order status transition event, and read the globally unique identifier string of the order, the unit code set of the inventory quantity of the traded goods, the set of the quantity of goods traded, the set of the unit price of the goods traded, the buyer member identifier string and the seller store identifier string from the event body, and combine the read information into an order dimension information group.

[0032] The event aggregation service, acting as a consumer client, connects to a designated storage partition of the "original order event subject" using the software development kit provided by the distributed message queue system. It then sequentially retrieves the binary data of order status transition events stored within this partition, according to the message submission offset order. For each retrieved data item, it first deserializes it into a data exchange format document object in memory. Then, it accesses this document object by key, extracts the globally unique identifier string O_GUID for the order and assigns it to a temporary string variable; extracts the inventory unit code set SKU_Set for the traded goods and assigns it to a list type variable; extracts the quantity set Qty_Set and the unit price set Price_Set for the traded goods and assigns them to their respective list type variables; and extracts the buyer member identifier string Buyer_ID and the seller store identifier string Seller_ID and assigns them to string variables. All the above fields extracted from the same order status transition event subject are combined and encapsulated as a whole into a temporary data structure object named "Order Dimension Information Group". This temporary data structure object exists in memory as a key-value pair mapping and contains attributes such as O_GUID, SKU_Set, Qty_Set, Price_Set, Buyer_ID, and Seller_ID.

[0033] Step S122: Pull out the bill status transition events sequentially from the bill status transition topic storage partition of the distributed message queue system, parse the event body of the bill status transition event, read the globally unique invoice identifier string, invoice type descriptor, invoice tax amount value and the associated globally unique order identifier string set from the event body, and combine the read information into a bill dimension information group.

[0034] Simultaneously, or sequentially, another consumer thread of the event aggregation service connects to a designated storage partition of the "original invoice event subject," and pulls invoice status transition events sequentially according to message offset order in the same way. After deserializing each invoice event data, the following are extracted by key name: the globally unique invoice identifier string I_GUID, assigned to a string variable; the invoice type descriptor I_Type, assigned to an enumeration or string variable; the invoice tax amount value I_Tax_Amt, assigned to a long integer variable; and the associated globally unique order identifier string set Ref_O_GUID_Set, assigned to a list type variable. All the above fields extracted from the same invoice status transition event body are combined and encapsulated into a temporary data structure object named Invoice Dimension Information Group. This temporary data structure object contains attributes such as I_GUID, I_Type, I_Tax_Amt, and Ref_O_GUID_Set.

[0035] Step S123: Retrieve fund transfer status change events sequentially from the fund transfer status change topic storage partition of the distributed message queue system, parse the event body of the fund transfer status change event, and read the fund transfer transaction serial number string, payer bank account string, payee bank account string, fund transfer amount, fund transfer completion timestamp, and associated globally unique identifier string of order or globally unique identifier string of invoice from the event body, and combine the read information into a fund dimension information group.

[0036] Similarly, another consumer thread of the event aggregation service connects to the designated storage partition of the "original funds event topic" and sequentially pulls funds transfer status transition events. After deserializing each funds event data, the following are extracted by key: the funds transfer transaction serial number string F_SerialNo, assigned to a string variable; the payer's bank account string Payer_Acct and the payee's bank account string Payee_Acct, respectively assigned to string variables; the funds transfer amount value F_Amt, assigned to a long integer variable; the funds transfer completion timestamp F_Timestamp, assigned to a long integer variable; the funds transfer status descriptor F_Status, assigned to an enumeration or string variable; and the associated globally unique identifier string for the order or the globally unique identifier string Ref_O_or_I_GUID, assigned to a string variable. All the above fields extracted from the same funds transfer status transition event subject are combined and encapsulated into a temporary data structure object named Funds Dimension Information Group. This temporary data structure object contains attributes such as F_SerialNo, Payer_Acct, Payee_Acct, F_Amt, F_Timestamp, F_Status, and Ref_O_or_I_GUID.

[0037] Step S124: Extract the globally unique identifier string of the order from the order dimension information group as the first aggregation clue; extract each globally unique identifier string of the order from the set of globally unique identifier strings of the associated order in the bill dimension information group as the second aggregation clue; and extract the globally unique identifier string of the order or the globally unique identifier string of the invoice from the fund dimension information group as the third aggregation clue.

[0038] After obtaining dimensional information groups from three different themes, the event aggregation service begins extracting related clues to prepare connection points for subsequent aggregation. For each order dimensional information group, the O_GUID attribute value is extracted and used as the first aggregation clue. For each invoice dimensional information group, its Ref_O_GUID_Set list is traversed, and each globally unique identifier string element for an order in the list is used as the second aggregation clue. For each funds dimensional information group, the Ref_O_or_I_GUID attribute value is extracted and used as the third aggregation clue. These clues are essentially business primary keys used to link events from different data sources.

[0039] Step S125: Perform string equivalence comparison on each globally unique identifier string of the first aggregated clue, the second aggregated clue, and the third aggregated clue, and aggregate the order dimension information group, bill dimension information group, and fund dimension information group corresponding to all successfully matched globally unique identifier strings of the same order into the same temporary aggregation storage area.

[0040] The event aggregation service launches a correlation analysis engine, which maintains a hash table as a temporary aggregation storage area, using strings as keys and mappings as values. The engine registers all extracted first aggregation threads (O_GUID) as keys in the hash table. Then, the engine iterates through all bill dimension information groups, using each second aggregation thread (i.e., each element in Ref_O_GUID_Set) as the query key to search the hash table. If a match is found, a reference or copy of that bill dimension information group is added to the "Bill Information List" in the mapping value corresponding to that key. Next, the engine iterates through all funding dimension information groups, and for each third aggregation thread (Ref_O_or_I_GUID), it first determines whether the string is an order identifier or an invoice identifier. If it is an order identifier, it directly uses it as the query key to search the hash table and aggregate funding information; if it is an invoice identifier, it first needs to find the corresponding bill in the bill dimension information group using I_GUID, then find the associated order identifier in the bill's Ref_O_GUID_Set, and finally aggregate the funding information using the order identifier as the key. Through the above comparison and aggregation operations based on string equivalence, the hash table in the temporary aggregation storage area ultimately contains the globally unique identifier string key for each successful order, and its corresponding mapping value gathers all order dimension information groups, one or more invoice dimension information groups, and one or more funding dimension information groups related to that order.

[0041] Step S126: Within the temporary aggregation storage area, write the aggregated order dimension information group into the business information storage slot of the preset structure template, write the aggregated bill dimension information group into the bill information storage slot of the preset structure template, and write the aggregated fund dimension information group into the fund information storage slot of the preset structure template.

[0042] After information aggregation is complete, the event aggregation service defines a pre-defined structure template for a unified fusion transaction description structure. This pre-defined structure template is represented in memory as a complex data object with three main slots: a business information storage slot, whose data type is defined as capable of holding one order dimension information group object; a bill information storage slot, whose data type is defined as capable of holding a list of one or more bill dimension information group objects; and a funds information storage slot, whose data type is defined as capable of holding a list of one or more funds dimension information group objects. For each key in the hash table of the temporary aggregation storage area—that is, the globally unique identifier string of each successfully associated order—the service creates a new instance of the pre-defined structure template. Then, the order dimension information group object retrieved from the hash table mapping value is directly assigned to the business information storage slot of this template instance. The retrieved list of bill dimension information groups is assigned to the bill information storage slot as a whole. The retrieved list of funds dimension information groups is assigned to the funds information storage slot as a whole.

[0043] Step S127: Continuously monitor the writing status of the business information storage slot, bill information storage slot and fund information storage slot of the preset structure template. When all three slots have been written with non-empty information, mark the preset structure template as having complete information and output the preset structure template in the complete information state as the fusion transaction description structure.

[0044] The event aggregation service starts a status monitoring thread that periodically scans all created preset structure template instances. For each template instance, it checks whether its business information storage slot is non-empty, i.e., whether it has been assigned an order dimension information group; it checks whether the list object referenced by its invoice information storage slot exists and contains at least one element; and it checks whether the list object referenced by its funds information storage slot exists and contains at least one element. When a template instance meets all three conditions, the monitoring thread changes the instance's internal status field from "Building" to "Information Complete". Subsequently, the main loop of the event aggregation service removes the preset structure template instance in the information complete state from the temporary storage area and passes it as a complete fused transaction description structure through the output queue to the downstream accounting rule matcher for further processing. For instances that fail to reach the information complete state for an extended period, the system will handle the exception or mark it as pending order completion according to the timeout policy.

[0045] Step S130: Call the embedded accounting rule matcher to decompose the accounting elements of the integrated transaction description structure, and sequentially separate the revenue recognition element group, cost collection element group, tax calculation element group and accounts receivable / payable tracking element group from the integrated transaction description structure. Then, map and bind each separated element group with the accounting chart structure information and tax processing rule information in the static financial rule information set to generate a multi-dimensional accounting instruction set corresponding to the integrated transaction description structure.

[0046] After obtaining the integrated transaction description structure representing the complete transaction context, the next step is to call a specialized embedded accounting rule matcher to perform in-depth analysis and decomposition of the structure, transforming it into accounting instructions that the financial system can recognize.

[0047] Step S131: Input the fusion transaction description structure into the input terminal of the embedded accounting rule matcher. The embedded accounting rule matcher is internally configured with a business direction discrimination channel, a revenue element separation channel, a cost element separation channel, a tax element separation channel, and an inter-company element separation channel.

[0048] The event aggregation service passes the generated fused transaction description structure instance as input parameters to the unified entry function of the embedded accounting rule matcher. This embedded accounting rule matcher is logically designed as a composite processor containing multiple parallel or serial processing channels. These channels are: a business direction discrimination channel for identifying transaction types; a revenue element stripping channel for extracting revenue-related information; a cost element stripping channel for extracting cost-related information; a tax element stripping channel for extracting tax-related information; and a transaction element stripping channel for extracting counterparty and fund information. These channels work together to comprehensively decompose the input single structure.

[0049] Step S132: Scan the business information storage slots in the integrated transaction description structure through the business direction discrimination channel, read the buyer member identifier string and the seller store identifier string from the business information storage slots, compare the buyer member identifier string with the preset internal entity identifier library to generate the buyer identity tag, compare the seller store identifier string with the preset internal entity identifier library to generate the seller identity tag, and identify the transaction direction features based on the combination of the buyer identity tag and the seller identity tag.

[0050] Step S1321: The business direction determination channel sequentially reads the buyer member identifier string and the seller store identifier string from the business information storage slot of the integrated transaction description structure.

[0051] After activation, the business direction determination channel first locates the input fused transaction description structure. This channel directly accesses the pre-defined business information storage slot within this structure via a memory address reference. This slot stores a complete order dimension information group object. The channel calls the object's attribute reading method, following the field order in the data structure definition. First, it reads the buyer's member identifier string attribute and assigns its value to a local string variable, denoted as Buyer_ID. Next, it reads the seller's store identifier string attribute and assigns its value to another local string variable, denoted as Seller_ID. After reading these two core identifiers, the channel obtains the raw input data needed to determine the transaction direction.

[0052] Step S1322: Perform a complete match comparison between each of the read buyer member identifier strings and the internal entity identifier strings stored in the preset internal entity identifier library. If the buyer member identifier string matches any internal entity identifier string in the internal entity identifier library, an internal entity buyer tag is generated for the buyer member identifier string. If the buyer member identifier string does not match any internal entity identifier string in the internal entity identifier library, an external entity buyer tag is generated for the buyer member identifier string.

[0053] After obtaining the Buyer ID (Buyer member identifier string), the business direction determination channel initiates a string matching engine. This engine accesses an internal entity identifier library pre-loaded into an in-memory hash set. This library, loaded from the Enterprise Master Data Management System during system initialization, contains various identifier strings for all entities defined as internal entities (e.g., subsidiaries, branches, business units, internal employee virtual accounts, affiliated companies, etc. within the group), such as Unified Social Credit Code, internal employee ID, and internal supplier code, denoted as Internal_Entity_Set. The engine uses Buyer_ID as the query key and performs a constant-time inclusion check on the Internal_Entity_Set hash set. The check result is a Boolean value. If the return value is true, meaning Buyer_ID is exactly equal to a string element in the set, the buyer is determined to be an internal entity, and an enumerated label with the value INTERNAL_BUYER is generated for that buyer member identifier string, denoted as the internal entity buyer label. If the return value is false, meaning Buyer_ID is not in the set, the buyer is determined to be an external entity, and an enumeration type label with the value EXTERNAL_BUYER is generated, denoted as the external entity buyer label. This external entity buyer label is temporarily stored in the channel's context object and associated with Buyer_ID.

[0054] Step S1323: Perform a complete match comparison between each of the read seller store identifier strings and the internal entity identifier strings stored in the preset internal entity identifier library. If the seller store identifier string matches any internal entity identifier string in the internal entity identifier library, an internal entity seller tag is generated for the seller store identifier string. If the seller store identifier string does not match any internal entity identifier string in the internal entity identifier library, an external entity seller tag is generated for the seller store identifier string.

[0055] Similarly, for the seller's store identifier string Seller_ID, the string matching engine of the business direction determination channel performs the exact same operation. It uses Seller_ID as the query key and performs a full match search within the same pre-defined internal entity identifier library, Internal_Entity_Set. If the search is successful, meaning Seller_ID matches an internal entity identifier in the set, an enumeration type label with the value INTERNAL_SELLER is generated for the seller's store identifier string, denoted as the internal entity seller label. If the search fails, meaning Seller_ID is not in the internal entity identifier library, an enumeration label with the value EXTERNAL_SELLER is generated, denoted as the external entity seller label. The generated seller identity label is also stored in the channel's context object and associated with Seller_ID.

[0056] Step S1324: Combine and match the generated buyer identity tag with the seller identity tag. If the buyer identity tag is an external entity buyer tag and the seller identity tag is an internal entity seller tag, then identify the transaction direction feature corresponding to the current fused transaction description structure as the external sales revenue direction feature.

[0057] At this point, the channel context object has stored the buyer's identity tag and the seller's identity tag for this transaction. The logic judgment unit of the business direction determination channel reads these two tag values ​​and performs a combination and matching judgment. It first checks whether the buyer's identity tag is EXTERNAL_BUYER, and simultaneously checks whether the seller's identity tag is INTERNAL_SELLER. If both conditions are met, the logic judgment unit concludes that this transaction is an external entity (e.g., a regular consumer) purchasing goods or services from an internal entity of the enterprise (e.g., a self-operated store of M Commercial Group). According to accounting conventions, the above transaction type should be recognized as the enterprise's sales revenue. Therefore, the channel generates a transaction direction feature enumeration value for this merged transaction description structure, denoted as REVENUE_SALE, which is the external sales revenue category direction feature.

[0058] Step S1325: If the buyer's identity label is an internal entity buyer label and the seller's identity label is an external entity seller label, then identify the transaction direction feature corresponding to the current fusion transaction description structure as an external procurement cost type direction feature.

[0059] If the condition in step S1324 is not met, the logic judgment unit then checks the second combination: whether the buyer's identity label is INTERNAL_BUYER and the seller's identity label is EXTERNAL_SELLER. If both conditions are met, it indicates that the transaction is an internal entity of the enterprise (such as the group's purchasing department) purchasing goods or services from an external entity (such as a raw material supplier). The above transaction type should be recognized as the enterprise's procurement cost. Therefore, the channel generates a transaction direction feature enumeration value for the fused transaction description structure, denoted as COST_PURCHASE, which is the external procurement cost category direction feature.

[0060] Step S1326: If the buyer's identity label is an internal entity buyer label and the seller's identity label is an internal entity seller label, then identify the transaction direction feature corresponding to the current fusion transaction description structure as an internal circulation and settlement type direction feature.

[0061] If neither of the above two internal / external combinations holds true, the logic unit then checks a third combination: whether the buyer's identity label is INTERNAL_BUYER and whether the seller's identity label is INTERNAL_SELLER. If both conditions are true, it indicates that both the buyer and seller in the transaction are internal entities of the enterprise, such as factory A transferring raw materials to factory B within a group. These internal transactions do not generate external profits or losses and require internal settlement. Therefore, the channel generates a transaction direction feature enumeration value for the fused transaction description structure, denoted as INTERNAL_SETTLEMENT, which represents the internal transfer and settlement direction feature.

[0062] Step S1327: If the buyer's identity label is an external entity buyer label and the seller's identity label is an external entity seller label, then identify the transaction direction feature corresponding to the current fused transaction description structure as an external market transaction direction feature.

[0063] If none of the above combinations match, the logic judgment unit finally checks the fourth combination: whether the buyer's identity label is EXTERNAL_BUYER and whether the seller's identity label is EXTERNAL_SELLER. If both conditions are met, it indicates that the transaction occurred between two external entities, but this may be because M Business Group provided a transaction platform or intermediary services, or the transaction data was mistakenly collected. In the above cases, the company may not need to recognize its profit or loss, or only a small amount of platform service fee revenue may be recognized. The channel generates a transaction direction feature enumeration value for the fused transaction description structure, denoted as EXTERNAL_TRADE, which represents the external market transaction direction feature, for special processing in subsequent processes.

[0064] Step S1328: The identified transaction direction features are used as the output of the business direction discrimination channel and transmitted to the input of the revenue element separation channel, cost element separation channel, tax element separation channel and inter-company element separation channel respectively.

[0065] After completing the above logical judgment, the business direction determination channel encapsulates the final determined transaction direction feature enumeration value (such as REVENUE_SALE, COST_PURCHASE, INTERNAL_SETTLEMENT, or EXTERNAL_TRADE) into a standard message or as a parameter in a direct method call. This output is simultaneously broadcast or sequentially passed to the other four element stripping channels configured in the embedded accounting rule matcher: the revenue element stripping channel, the cost element stripping channel, the tax element stripping channel, and the accounts receivable / payable element stripping channel. These channels serve as the basis for each channel to determine whether to initiate the processing flow and how to set the accounting direction.

[0066] Step S133: Input the identified transaction direction features into the revenue element stripping channel. The revenue element stripping channel determines whether to trigger the revenue recognition operation based on the transaction direction features. When the revenue recognition operation is triggered, it reads the total order amount including tax from the business information storage slot of the integrated transaction description structure and reads the invoice tax amount from the invoice information storage slot of the integrated transaction description structure. The total order amount including tax is subtracted from the invoice tax amount to obtain the revenue amount to be recognized. The revenue amount to be recognized is then associated with the transaction direction features and encapsulated to generate a revenue recognition element group.

[0067] Step S1331: The revenue element stripping channel receives the transaction direction features transmitted by the business direction discrimination channel, and compares the received transaction direction features with the preset revenue trigger direction feature set. The preset revenue trigger direction feature set includes external sales revenue type direction features and external market transaction type direction features.

[0068] The revenue element stripping channel waits at its entry point for and receives transaction direction feature values, denoted as Direction_Feature, from the business direction discrimination channel. Internally, this business direction discrimination channel maintains a static, read-only set of trigger conditions, namely a preset revenue trigger direction feature set, denoted as Revenue_Trigger_Set. This revenue trigger direction feature set is defined during system design and includes all transaction types that ultimately need to trigger the revenue recognition process. According to financial standards, typical trigger directions include the external sales revenue direction feature REVENUE_SALE, and the external market transaction direction feature EXTERNAL_TRADE, which requires the recognition of platform service fee revenue or handling fee revenue under certain specific accounting models. The channel's logical comparison unit enumerates and compares the received Direction_Feature with each element in the Revenue_Trigger_Set.

[0069] Step S1332: If the received transaction direction feature matches any direction feature in the preset income trigger direction feature set, then the current fused transaction description structure is determined to trigger income recognition operation, and the income amount positioning process is started.

[0070] If the logic comparison unit finds that the value of Direction_Feature is equal to REVENUE_SALE or EXTERNAL_TRADE in Revenue_Trigger_Set, the judgment result is true, i.e., a hit. This means that the transaction meets the conditions for revenue recognition, and the channel's control flow will jump to the sub-process for revenue amount positioning and calculation. The channel's status flag is set to "Revenue Recognition Activated".

[0071] Step S1333: If the received transaction direction feature does not match any of the preset revenue trigger direction feature sets, it is determined that the current fused transaction description structure does not trigger the revenue recognition operation, the revenue element stripping process is terminated and an empty revenue recognition element group identifier is returned.

[0072] If the value of Direction_Feature is not in Revenue_Trigger_Set, for example, if COST_PURCHASE or INTERNAL_SETTLEMENT is received, the logical comparison unit determines the result as false, i.e., a miss. This means that this transaction does not involve revenue recognition, and the revenue element stripping channel does not need to perform any processing. The channel immediately terminates all subsequent operations and, according to the interface specification, returns a predefined empty object or null identifier to the upper-layer caller (i.e., the main control logic of the embedded accounting rule matcher), indicating that no revenue recognition element group has been generated.

[0073] Step S1334: After determining that the revenue recognition operation has been triggered, the revenue element stripping channel reads the total order amount including tax from the business information storage slot of the integrated transaction description structure and reads the invoice tax amount from the bill information storage slot of the integrated transaction description structure. The total order amount including tax is subtracted from the invoice tax amount, and the difference is taken as the revenue amount to be recognized.

[0074] With revenue recognition active, the revenue element stripping channel begins calculating the amount. First, it re-accesses the input merged transaction description structure via a reference. From the business information storage slot of this structure, it reads the total order amount (including tax), Ord_Amt_Tax. Next, it locates the invoice information storage slot of the same structure, which stores a list of one or more invoice dimension information group objects. The channel selects a master invoice according to default rules (e.g., taking the first invoice in the list with a status of "normal") or based on the invoice type descriptor priority. From the selected invoice dimension information group object, it reads the invoice tax amount, I_Tax_Amt. Then, the arithmetic logic unit within the channel performs a subtraction operation, subtracting the subtrahend I_Tax_Amt from the minuend Ord_Amt_Tax, and storing the difference in a new long integer variable, denoted as Rev_Amt. This Rev_Amt is the revenue amount to be recognized, representing the taxable sales revenue after deducting value-added tax.

[0075] Step S1335: Associate the extracted revenue amount to be recognized with the received transaction direction features to generate a revenue recognition element group containing revenue amount values ​​and direction feature labels, and pass the revenue recognition element group to the linking process with the accounting chart of accounts structure information.

[0076] Finally, the revenue element stripping channel encapsulates the calculated revenue amount to be recognized (Rev_Amt), the initially received transaction direction feature (Direction_Feature), and other potentially needed contextual information (such as product category and business department) into a newly created data transfer object. This data transfer object is designed as a key-value pair mapping structure, containing at least two key-value pairs: the value corresponding to the "revenue amount" key is Rev_Amt, and the value corresponding to the "direction feature" key is Direction_Feature. This encapsulated data transfer object is the revenue recognition element group. The channel passes this object as the output of its processing flow to the subsequent processing stage in the embedded accounting rule matcher responsible for binding with accounting subjects, i.e., waiting for the call to step S137.

[0077] Step S134: Input the identified transaction direction features into the cost element stripping channel. The cost element stripping channel determines whether to trigger the cost aggregation operation based on the transaction direction features. When the cost aggregation operation is triggered, it reads the commodity transaction quantity set and commodity transaction unit price set from the business information storage slot of the fused transaction description structure. After performing item-by-item multiplication on the commodity transaction quantity set and commodity transaction unit price set, it accumulates to generate the cost amount to be aggregated. Then, it associates and encapsulates the cost amount to be aggregated with the transaction direction features to generate a cost aggregation element group.

[0078] Step S1341: The cost element stripping channel receives the transaction direction features transmitted by the business direction discrimination channel, and compares the received transaction direction features with the preset cost trigger direction feature set. The preset cost trigger direction feature set includes external procurement cost type direction features and internal circulation settlement type direction features.

[0079] Parallel or sequential with the revenue element stripping channel, the cost element stripping channel also receives the transaction direction feature value (Direction_Feature) transmitted from the business direction determination channel. Internally, this cost element stripping channel maintains another static set of trigger conditions, namely a preset cost trigger direction feature set, denoted as Cost_Trigger_Set. This set contains all transaction types that should be recognized as costs or expenses, typically including the external procurement cost direction feature (COST_PURCHASE) and the internal transfer settlement direction feature (INTERNAL_SETTLEMENT), because although internal transfers do not generate external profits or losses, costs need to be accumulated between cost centers. The channel's logical unit compares the Direction_Feature with the elements in the Cost_Trigger_Set.

[0080] Step S1342: If the received transaction direction feature matches any direction feature in the preset cost trigger direction feature set, then the current fused transaction description structure is determined to trigger the cost aggregation operation, and the cost amount positioning process is started.

[0081] If the value of Direction_Feature matches COST_PURCHASE or INTERNAL_SETTLEMENT in Cost_Trigger_Set, it is considered a hit. The channel determines that this transaction has triggered a cost aggregation operation, its control flow transfers to the cost amount calculation sub-process, and sets the channel status to "cost aggregation activated".

[0082] Step S1343: If the received transaction direction feature does not match any of the preset cost trigger direction feature sets, it is determined that the current fusion transaction description structure does not trigger the cost aggregation operation, the cost element stripping process is terminated and an empty cost aggregation element group identifier is returned.

[0083] If the value of Direction_Feature is REVENUE_SALE or EXTERNAL_TRADE and is not in Cost_Trigger_Set, it is considered a miss. The cost element stripping channel immediately terminates processing and returns an empty cost aggregation element group identifier to the upper-level caller, indicating that cost aggregation is not required for this transaction.

[0084] Step S1344: After determining that the cost aggregation operation is triggered, the cost element stripping channel sequentially reads the set of commodity transaction quantity and the set of commodity transaction unit price from the business information storage slot of the integrated transaction description structure.

[0085] When cost aggregation is active, the channel begins preparing to calculate the cost amount. It accesses the business information storage slot of the merged transaction description structure and reads two core list-type data: the product transaction quantity set Qty_Set and the product transaction unit price set Price_Set. The channel controller ensures that these two lists are arranged in the same order, that is, the i-th element in the list collectively describes the transaction information of the i-th product.

[0086] Step S1345: Perform a multiplication operation on the transaction quantity of each commodity in the transaction quantity set and the corresponding transaction price in the transaction price set to generate the median cost amount for each type of transaction commodity.

[0087] The channel initializes a loop, with the loop counter i starting from 0 and ending when the length of the list is decremented by 1. In each loop iteration, it retrieves the i-th element from Qty_Set, denoted as Qty_i, and retrieves the i-th element from Price_Set, denoted as Price_i. Then, the arithmetic logic unit within the channel performs a multiplication operation to calculate the median cost of the item, denoted as Cost_Item_i. This operation can be described as multiplying the i-th quantity value by the i-th unit value.

[0088] Step S1346: Sum the median cost amount of all generated transaction goods, and use the summation result as the cost amount to be aggregated.

[0089] After calculating Cost_Item_i in each loop iteration, the channel immediately adds it to an accumulator variable Total_Cost. The accumulator Total_Cost is initialized to 0 before the loop begins. After the loop has traversed all items, the value stored in Total_Cost is the sum of the costs of all items. This sum is considered the total cost to be collected for this transaction and is denoted as the cost amount to be collected, Cost_Acc.

[0090] Step S1347: Associate the generated cost amount to be collected with the received transaction direction features to generate a cost collection element group containing cost amount values ​​and direction feature labels, and transfer the cost collection element group to the linking process with the chart of accounts structure information.

[0091] The channel associates the calculated cost amount (Cost_Acc) to be aggregated with the initially received transaction direction feature (Direction_Feature). These are encapsulated together in a new data transfer object. This object contains a "Cost Amount" key and a "Direction Feature" key, with values ​​of Cost_Acc and Direction_Feature, respectively. This encapsulated object is the cost aggregation element group. The channel outputs this object and passes it to the subsequent stage responsible for account binding, i.e., awaiting the call to step S138.

[0092] Step S135: Input the identified transaction direction features into the tax element stripping channel. The tax element stripping channel determines whether to trigger the tax calculation operation based on the transaction direction features. When it is determined that the tax calculation operation has been triggered, it reads the invoice type descriptor and the invoice tax amount value from the invoice information storage slot of the fused transaction description structure, and associates and encapsulates the invoice type descriptor and the invoice tax amount value to generate a tax calculation element group.

[0093] For example, in step S1351: the tax element stripping channel receives the transaction direction features transmitted by the business direction discrimination channel, and compares the received transaction direction features with the preset tax trigger direction feature set. The preset tax trigger direction feature set includes external sales revenue type direction features and external procurement cost type direction features.

[0094] The tax element stripping channel receives the transaction direction feature value (Direction_Feature) transmitted from the business direction determination channel. Internally, this channel maintains a preset tax trigger direction feature set, denoted as Tax_Trigger_Set. According to tax management requirements, both sales (generating output tax) and purchases (generating input tax) may involve tax calculation and recording. Therefore, this set includes the external sales revenue direction feature REVENUE_SALE and the external purchase cost direction feature COST_PURCHASE. The channel's logical unit compares the Direction_Feature with the Tax_Trigger_Set.

[0095] Step S1352: If the received transaction direction feature matches any direction feature in the preset tax trigger direction feature set, then the current fused transaction description structure is determined to trigger the tax calculation operation, and the tax information location process is started.

[0096] If the value of Direction_Feature is equal to REVENUE_SALE or COST_PURCHASE, it is considered a hit. The channel determines that this transaction has triggered a tax calculation operation, its control flow transfers to the tax information extraction sub-process, and sets the channel status to "tax calculation activated".

[0097] Step S1353: If the received transaction direction feature does not match any of the preset tax trigger direction feature sets, it is determined that the current fused transaction description structure does not trigger the tax calculation operation, the tax element stripping process is terminated and the empty tax calculation element group identifier is returned.

[0098] If the value of Direction_Feature is INTERNAL_SETTLEMENT or EXTERNAL_TRADE and is not in Tax_Trigger_Set, it is considered a miss. The tax element stripping channel immediately terminates processing and returns an empty tax calculation element group identifier to the upper-level caller.

[0099] Step S1354: After determining that the tax calculation operation has been triggered, the tax element stripping channel reads the invoice type descriptor and the invoice tax amount value from the invoice information storage slot of the fused transaction description structure.

[0100] When tax calculation is active, the channel begins extracting tax-related information. It accesses the invoice information storage slot within the integrated transaction description structure, which contains a list of invoice dimension information groups. Following preset invoice selection rules (e.g., prioritizing invoices with non-empty tax amounts and compliant invoice type descriptors), the channel selects the most crucial invoice information from the list. From the selected invoice dimension information group object, it reads two key fields: the invoice type descriptor I_Type and the invoice tax amount I_Tax_Amt.

[0101] Step S1355: Match the read invoice type descriptor with the preset list of taxable invoice types. If the invoice type descriptor matches any type description in the list of taxable invoice types, then use the read invoice tax amount as the tax payable amount.

[0102] To ensure the accuracy of tax amounts, the channel incorporates a verification step that accesses a pre-defined list of taxable invoice types. This list is an enumerated set containing invoice types recognized by the tax authorities as valid bases for tax deduction or calculation, such as VAT invoices. The channel compares the read I_Type with this list. If the I_Type exists in the list, it indicates a compliant tax invoice, and the channel directly determines the tax payable as I_Tax_Amt from the invoice's value, denoted as Tax_Amt.

[0103] Step S1356: If the invoice type descriptor does not match any type description in the list of taxable invoice types, the total amount of the order including tax is read from the business information storage slot of the merged transaction description structure, and the total amount of the order including tax is multiplied by the preset default tax rate to generate a simulated tax amount as the tax payable.

[0104] If I_Type is not in the list of taxable invoice types, for example, if only a regular receipt or VAT invoice (which is not deductible in some scenarios) is obtained, the channel initiates fallback calculation logic. This logic returns to the business information storage slot in the fused transaction description structure and reads the total tax-inclusive amount of the order, Ord_Amt_Tax. Simultaneously, based on the business scenario of the transaction (such as product type and seller's taxpayer identity), the channel queries and loads a preset default tax rate, Default_Rate, from the tax processing rules information. Then, the arithmetic logic unit performs a multiplication operation, multiplying Ord_Amt_Tax by Default_Rate. The calculated product is used as a simulated, estimated tax amount, which is then determined as the final tax payable, Tax_Amt.

[0105] Step S1357: Combine the read invoice type descriptor and the determined tax payable value to generate a tax calculation element group containing the invoice type label and the tax amount value, and pass the tax calculation element group to the linking process with the tax processing rule information.

[0106] The channel associates and encapsulates the original invoice type descriptor I_Type and the final determined tax amount Tax_Amt into a new data transfer object. This data transfer object contains at least a "Invoice Type" key and a "Tax Amount Value" key, with values ​​of I_Type and Tax_Amt, respectively. This encapsulated object constitutes the tax calculation element group. The channel outputs this object and passes it to the subsequent stage responsible for binding with tax processing rule information, i.e., awaiting the call to step S139.

[0107] Step S136: Input the identified transaction direction features into the transaction element stripping channel. The transaction element stripping channel determines whether to trigger the transaction tracking operation based on the transaction direction features. When the transaction tracking operation is triggered, it reads the payer's bank account string, the payee's bank account string, and the fund transfer completion timestamp from the fund information storage slot of the fused transaction description structure, and associates and encapsulates the payer's bank account string, the payee's bank account string, and the fund transfer completion timestamp to generate a transaction tracking element group.

[0108] For example, in step S1361: the transaction direction features transmitted by the business direction discrimination channel are received by the transaction element stripping channel, and the received transaction direction features are compared with the preset transaction trigger direction feature set. The preset transaction trigger direction feature set includes external sales revenue type direction features and external procurement cost type direction features.

[0109] The transaction direction feature (Direction_Feature) transmitted from the business direction determination channel is received by the transaction direction feature channel. This business direction determination channel internally maintains a preset transaction trigger direction feature set, denoted as ARAP_Trigger_Set. Since receivables and payables (i.e., accounts receivable and payable) typically arise from external sales and purchase activities, this set includes the external sales revenue feature REVENUE_SALE and the external purchase cost feature COST_PURCHASE. The channel's logical unit compares the Direction_Feature with the ARAP_Trigger_Set.

[0110] Step S1362: If the received transaction direction feature matches any direction feature in the preset set of incoming and outgoing trigger direction features, then the current fused transaction description structure is determined to trigger the incoming and outgoing tracking operation, and the incoming and outgoing information positioning process is started.

[0111] If the value of Direction_Feature equals REVENUE_SALE or COST_PURCHASE, it is considered a hit. The channel determines that this transaction has triggered a transaction tracking operation, meaning that accounts receivable or payable to customers or suppliers need to be recorded. The control flow moves to the transaction information extraction sub-process, and the channel status is set to "Transaction Tracking Activated".

[0112] Step S1363: If the received transaction direction feature does not match any of the preset transaction trigger direction feature sets, it is determined that the current merged transaction description structure does not trigger the transaction tracking operation, the transaction element stripping process is terminated and an empty transaction tracking element group identifier is returned.

[0113] If the value of Direction_Feature is INTERNAL_SETTLEMENT or EXTERNAL_TRADE and is not in ARAP_Trigger_Set, it is considered a miss. The transaction feature stripping channel immediately terminates processing and returns an empty transaction tracking feature group identifier to the upper-level caller, indicating that no transaction record needs to be generated for this transaction.

[0114] Step S1364: After determining that the transaction tracking operation has been triggered, the transaction element stripping channel reads the payer's bank account string, the payee's bank account string, and the fund transfer completion timestamp from the fund information storage slot of the fused transaction description structure.

[0115] With transaction tracking active, the channel begins extracting information related to fund flows. It accesses the fund information storage slot within the merged transaction description structure, which stores a list of one or more fund dimension information group objects. The channel typically selects the first successful fund transfer record, or the most relevant record based on amount matching rules. From the selected fund dimension information group object, it reads three core fields: the payer's bank account string (Payer_Acct), the payee's bank account string (Payee_Acct), and the fund transfer completion timestamp (F_Timestamp).

[0116] Step S1365: Based on the received transaction direction characteristics, if the transaction direction characteristics are external sales revenue type characteristics, then mark the read payer's bank account string as the receivables source identifier, and mark the read payee's bank account string as the receivables aggregator identifier.

[0117] The channel uses the pre-received Direction_Feature to semantically mark the read bank accounts. If the Direction_Feature value is REVENUE_SALE (external sale), then from the payer's perspective, the customer (payer) is the source from whom we will collect payments in the future, so Payer_Acct is marked as the source of accounts receivable. From the payee's perspective, the company's own bank account (payee) is the final destination for accounts receivable, so Payee_Acct is marked as the collector of accounts receivable. These markings will be recorded in the subsequently generated element group to guide the completion of intercompany auxiliary accounting in the detailed ledger.

[0118] Step S1366: If the transaction direction feature is the external procurement cost type, then mark the read payer's bank account string as the payer's account payer identifier, and mark the read payee's bank account string as the payee's account receiver identifier.

[0119] If the value of Direction_Feature is COST_PURCHASE (external procurement), then from the payer's perspective, the company's own bank account (the payer) is the party that will need to make payments in the future, so Payer_Acct is marked as the payer's identifier. From the payee's perspective, the supplier's bank account (the payee) is the recipient of the payables, so Payee_Acct is marked as the recipient's identifier.

[0120] Step S1367: Associate the marked payer's bank account string or payee's bank account string with the read fund transfer completion timestamp to generate a transaction tracking element group containing the counterparty identifier and the time of fund arrival, and pass the transaction tracking element group to the step of binding with the accounting chart structure information.

[0121] Finally, based on the transaction direction, the channel associates and encapsulates the business semantic markers (such as the accounts receivable source identifier) ​​and their corresponding specific account strings with the fund transfer completion timestamp F_Timestamp. The generated data transfer object contains the "counterparty identifier" (i.e., the specific account string), the marker type (such as "source"), and the "fund arrival time" (i.e., F_Timestamp). This encapsulated object is the transaction tracking element group. The channel outputs this object and passes it to the subsequent link responsible for binding with the chart of accounts structure information, i.e., waiting for the call in step S1310.

[0122] Step S137: Read the chart of accounts structure information from the static financial rules information set, locate the corresponding revenue account code in the chart of accounts structure information according to the transaction direction characteristics carried in the revenue recognition element group, bind the located revenue account code with the revenue recognition element group to generate a revenue recognition sub-instruction carrying the revenue account code.

[0123] After stripping the various element groups, the accounting rule matcher begins mapping and binding elements to rules. First, for the revenue recognition element group, if it is not empty, the rule matcher reads the previously loaded chart of accounts structure information from memory. Based on the transaction direction characteristics (such as REVENUE_SALE) carried in the revenue recognition element group, and potentially implicit information such as product type and business department, the rule matcher locates the specific, lowest-level revenue category account code, denoted as Rev_Account_Code, from accounts with the profit and loss category distinction field in the chart of accounts structure information, according to a preset mapping logic (e.g., sales of goods correspond to "main business revenue," sales of scrap materials correspond to "other business revenue"). Then, the account code string Rev_Account_Code is added as a new attribute to the original revenue recognition element group key-value pair mapping, forming a new mapping containing the account code, denoted as the revenue recognition sub-instruction.

[0124] Step S138: Read the chart of accounts structure information from the static financial rule information set, locate the corresponding cost account code in the chart of accounts structure information according to the transaction direction characteristics carried in the cost collection element group, bind the located cost account code with the cost collection element group to generate a cost collection sub-instruction carrying the cost account code.

[0125] Similarly, for cost aggregation element groups, the rule matcher, based on the transaction direction characteristics they carry (such as COST_PURCHASE), locates the corresponding cost category account code in the chart of accounts structure information, from accounts whose account category distinction field is cost. For example, the cost of goods purchased corresponds to "Main Business Costs," denoted as Cost_Account_Code. This account code string, Cost_Account_Code, is added to the original cost aggregation element group mapping to form a cost aggregation sub-instruction.

[0126] Step S139: Read tax processing rule information from the static financial rule information set, locate the corresponding tax jurisdiction code and applicable tax rate value in the tax processing rule information according to the invoice type descriptor carried in the tax calculation element group, bind the located tax jurisdiction code and applicable tax rate value with the tax calculation element group to generate a tax calculation sub-instruction carrying the tax jurisdiction identifier.

[0127] For tax calculation element groups, the rule matcher reads tax processing rule information from memory. Based on the invoice type descriptor I_Type and the region to which the seller's taxpayer identification number Seller_TaxID belongs, it queries the tax processing rule information table to locate the corresponding tax jurisdiction code Tax_Region_Code and applicable tax rate Tax_Rate. These two fields are added as new attributes to the original tax calculation element group mapping, forming a tax calculation sub-instruction carrying the tax jurisdiction identifier.

[0128] Step S1310: Read the chart of accounts structure information from the static financial rule information set, locate the corresponding account code in the chart of accounts structure information based on the payer's bank account string or payee's bank account string carried in the account tracking element group, bind the located account code with the account tracking element group to generate an account tracking sub-instruction carrying the account code.

[0129] For accounts receivable / payable tracking element groups, the rule matcher reads the chart of accounts structure information again. Based on the tagged counterparty identifiers carried in the element group (such as the bank account number of the source of accounts receivable), or according to the default accounts receivable / payable mapping rules (such as "Other Receivables - Internal Units" for internal transactions and "Accounts Receivable" for external customers), the corresponding accounts receivable / payable account code, denoted as AR_AP_Account_Code, is located in accounts with the account category distinction field being asset or liability. This account code string AR_AP_Account_Code is then added to the original accounts receivable / payable tracking element group mapping, forming an accounts receivable / payable tracking sub-instruction carrying the accounts receivable / payable account code.

[0130] Step S1311: Combine the revenue recognition sub-instruction, cost collection sub-instruction, tax calculation sub-instruction, and transaction tracking sub-instruction to generate a multi-dimensional accounting instruction set corresponding to the integrated transaction description structure.

[0131] Finally, the accounting rule matcher places all the sub-instruction objects generated in this process—one for revenue recognition, one for cost aggregation, one for tax calculation, and one for transaction tracking (or a special placeholder if any are empty)—into an ordered list data structure. This list constitutes the multi-dimensional accounting instruction set corresponding to the initially input fusion transaction description structure.

[0132] Step S140: Perform instruction merging processing on the posting direction indication information and account hierarchy path information carried in the multi-dimensional accounting instruction set to generate a general ledger update instruction stream containing general ledger account summary information and subsidiary ledger account occurrence information. Inject the general ledger update instruction stream into the general ledger processing module of the enterprise internal resource planning system to drive the synchronous update operation of the general ledger and subsidiary ledger.

[0133] After obtaining the multi-dimensional accounting instruction set for a single integrated transaction, the final step is to convert it into actual update operations on the general ledger system in batches or in real time, so as to achieve the final integration of business and financial data and accounting records.

[0134] Step S141: Parse the multidimensional accounting instruction set and separate the revenue recognition sub-instruction carrying the revenue account code, the cost collection sub-instruction carrying the cost account code, the tax calculation sub-instruction carrying the tax jurisdiction identifier, and the transaction tracking sub-instruction carrying the transaction account code from the multidimensional accounting instruction set.

[0135] In this embodiment, a multidimensional accounting instruction set list is received from the accounting rule matcher. For example, by traversing each sub-instruction object in the multidimensional accounting instruction set list, the parser can accurately identify and separate the following by examining the instruction type identifier field carried within the object: revenue recognition sub-instruction containing a revenue account code field; cost collection sub-instruction containing a cost account code field; tax calculation sub-instruction containing a tax jurisdiction identifier field; and accounts receivable / payable tracking sub-instruction containing an accounts receivable / payable code field. For each separated sub-instruction, the parser extracts all its internal attributes and values ​​and temporarily stores them in memory.

[0136] Step S142: Extract the revenue account code and the amount of revenue to be recognized from the revenue recognition sub-instruction; extract the cost account code and the amount of cost to be collected from the cost collection sub-instruction; extract the tax jurisdiction identifier and the amount of tax payable from the tax calculation sub-instruction; and extract the accounts receivable / payable code and the counterparty identifier from the accounts receivable / payable tracking sub-instruction.

[0137] The parser performs refined field extraction for each sub-instruction. From the revenue recognition sub-instruction, it extracts the revenue account code Rev_Account_Code and the amount of revenue to be recognized, Rev_Amt. From the cost collection sub-instruction, it extracts the cost account code Cost_Account_Code and the amount of cost to be collected, Cost_Acc. From the tax calculation sub-instruction, it extracts the tax jurisdiction identifier (e.g., the tax jurisdiction code Tax_Region_Code) and the tax payable value, Tax_Amt. From the accounts receivable / payable tracking sub-instruction, it extracts the accounts receivable / payable code AR_AP_Account_Code and the counterparty identifier (e.g., an encrypted bank account number or customer code).

[0138] Step S143: Based on the extracted revenue account code, locate the corresponding revenue general ledger account level path and revenue subsidiary ledger account code in the chart of accounts structure information, associate the revenue amount to be identified with the located revenue general ledger account level path and revenue subsidiary ledger account code, and generate a revenue accounting unit.

[0139] The general ledger update service queries the in-memory chart of accounts structure information again based on the extracted account codes. For the revenue account code Rev_Account_Code, it recursively searches for its parent account codes until it reaches the first-level account, constructing a complete hierarchical path for revenue-related general ledger accounts, such as "6001-Main Business Revenue". Simultaneously, Rev_Account_Code itself serves as the revenue-related subsidiary ledger account code. The service creates a revenue-related posting unit metadata structure, which contains three core parts: posting direction (revenue increases are recorded on the credit side based on account nature), account path (i.e., the general ledger hierarchical path), subsidiary account code, and amount Rev_Amt. This posting unit is temporarily stored in an in-memory list.

[0140] Step S144: Based on the extracted cost account codes, locate the corresponding cost general ledger account hierarchical path and cost subsidiary ledger account codes in the chart of accounts structure information, associate the cost amount to be aggregated with the located cost general ledger account hierarchical path and cost subsidiary ledger account codes, and generate cost accounting units.

[0141] Similarly, based on the cost account code (Cost_Account_Code), construct the cost-class general ledger account hierarchical path in the chart of accounts structure information, and use itself as the cost-class subsidiary ledger account code. Create a cost-class accounting unit, including the posting direction (cost increases are recorded on the debit side), account path, subsidiary account code, and amount (Cost_Acc), and temporarily store it in a list.

[0142] Step S145: Based on the extracted tax jurisdiction identifier, locate the corresponding tax payable account code in the tax processing rule information, associate the tax payable amount with the located tax payable account code, and generate a tax-related accounting unit.

[0143] Based on the extracted tax jurisdiction identifier (e.g., tax jurisdiction code Tax_Region_Code), the corresponding predefined tax payable account code is retrieved from the tax processing rule information, such as "2221-VAT Payable-Output Tax". The service creates a tax-related accounting unit, which includes the posting direction (increase in liabilities is recorded on the credit side), the account path (constructed in reverse based on the account code), the detailed account code (i.e., the account code itself), and the amount Tax_Amt, and temporarily stores them in a list.

[0144] Step S146: Based on the extracted account codes, locate the corresponding general ledger account hierarchical path and subsidiary ledger account codes in the chart of accounts structure information, associate the counterparty identifier with the located general ledger account hierarchical path and subsidiary ledger account codes, and generate an account posting unit.

[0145] Based on the extracted account code AR_AP_Account_Code, construct its hierarchical path in the general ledger account information of the chart of accounts, and use it as the account code for the subsidiary ledger account of the same category. Create an account-related journal entry, including the posting direction (debit for asset increases or credit for liability increases, depending on the specific account), account path, subsidiary ledger account code, and amount (same as the revenue or cost amount, representing the amount of receivables and payables). Simultaneously, associate this journal entry with the counterparty identifier so that the specific counterparty can be recorded in the subsidiary ledger. This entry is also temporarily stored in a list.

[0146] Step S147: Collect the generated revenue accounting units, cost accounting units, tax accounting units, and accounts receivable / payable accounting units. Group and merge all accounting units according to the general ledger account hierarchy path. Accumulate and summarize the transaction amounts of all accounting units under the same general ledger account hierarchy path to generate the current period transaction summary value corresponding to each general ledger account hierarchy path as the general ledger account summary information.

[0147] At this point, multiple accounting entries conforming to the double-entry bookkeeping principle have been generated for each single transaction (e.g., debit: costs, accounts receivable / payable; credit: revenue, taxes). The general ledger update service collects these accounting entries. Then, a merge processor is initiated, using the "account path" within the accounting entry as the grouping key to group all accounting entries in the list. For groups of accounting entries with the same account path, the merge processor sums up the amounts according to the debit and credit directions. For example, the sum of all credit "main business revenue" amounts yields the total credit amount for that general ledger account in the current period. Finally, the merge processor generates a record for each general ledger account, containing the account path and the net amount for the current period. This set of records is called the general ledger account summary information.

[0148] Step S148: Group and merge all accounting units according to the subsidiary ledger account code, arrange multiple transactions under the same subsidiary ledger account code into a chronological transaction sequence according to the order in which the accounting units were generated, and use the chronological transaction sequence as the subsidiary ledger account transaction information.

[0149] Simultaneously, the merge processor uses the "detailed account code" and the associated "counterparty identifier" within the accounting unit as finer-grained grouping keys to further group the accounting units in the list. For each group, all accounting units are sorted according to their generation order (or event timestamp) to form a chronological list. Each element in the list records information such as the date the detailed account occurred, voucher number, summary, debit or credit amount, and balance direction. The collection of these chronological lists is called the detailed account occurrence information.

[0150] Step S149: Encapsulate the generated general ledger account summary information and subsidiary ledger account occurrence information into a general ledger update instruction stream in a structured data format. Transmit the general ledger update instruction stream to the general ledger processing module through the general ledger write interface opened by the enterprise internal resource planning system. This triggers the general ledger processing module to update the account balances in the general ledger balance sheet based on the general ledger account summary information, and to append the corresponding chronological occurrence record rows to the subsidiary ledger based on the subsidiary ledger account occurrence information.

[0151] Finally, the general ledger update service encapsulates the general ledger account summary information generated in step S147 and the subsidiary ledger account occurrence information generated in step S148 into a unified structured document, such as a string in Extensible Markup Language or JavaScript Object Notation, according to the input data format required by the general ledger processing module of the internal resource planning system, forming a general ledger update instruction stream. The service sends this instruction stream as a request payload to the general ledger processing module by calling the Hypertext Transfer Protocol interface exposed by the internal resource planning system or by directly calling its stored procedures through a database connection. Upon receiving the instruction, the general ledger processing module parses the general ledger account summary information and updates the corresponding account balances in the general ledger balance sheet it maintains by adding or reducing entries. Simultaneously, the module parses the subsidiary ledger account occurrence information and appends a new record to each chronological occurrence in the physical storage table of the subsidiary ledger (such as a relational database table). This record contains all details, including date, voucher number, account code, counterparty, debit amount, and credit amount. Through the above synchronous update operation, the end-to-end automated flow and recording of business and financial data from original events to final accounting books is realized.

[0152] In one exemplary embodiment, a financial automation system based on cross-platform business and financial data aggregation and AI intelligent accounting is provided. This financial automation system based on cross-platform business and financial data aggregation and AI intelligent accounting can be a terminal, server, etc., and its internal structure diagram can be as follows. Figure 2As shown, this financial automation system based on cross-platform business and financial data aggregation and AI intelligent accounting includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, near-field communication, or other technologies. When the computer program is executed by the processor, it implements a financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device can be a touch layer covering the display screen, or a button, trackball, or touchpad set on the shell of a financial automation system based on cross-platform business and financial data aggregation and AI intelligent accounting, or an external keyboard, touchpad, or mouse, etc.

[0153] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting, characterized in that, The method includes: The system acquires raw business event streams from multiple external business platform data sources associated with the enterprise's transaction activities, as well as a set of static financial rule information extracted from the enterprise's internal resource planning system. The raw business event streams include order status change events, invoice status change events, and fund transfer status change events. The set of static financial rule information includes accounting chart structure information and tax processing rule information. The order status change events, bill status change events, and fund transfer status change events in the original business event flow are processed to mine the inter-event correlation clues. Based on the mined correlation clues, the order status change events, bill status change events, and fund transfer status change events belonging to the same transaction context are aggregated across events to generate a fused transaction description structure. The embedded accounting rule matcher is invoked to decompose the accounting elements of the integrated transaction description structure. The revenue recognition element group, cost collection element group, tax calculation element group, and accounts receivable / payable tracking element group are separated from the integrated transaction description structure in sequence. Each separated element group is then mapped and bound to the accounting subject table structure information and tax processing rule information in the static financial rule information set to generate a multi-dimensional accounting instruction set corresponding to the integrated transaction description structure. The accounting direction indication information and account hierarchy path information carried in the multi-dimensional accounting instruction set are processed by instruction merging to generate a general ledger update instruction stream containing general ledger account summary information and subsidiary ledger account occurrence information. The general ledger update instruction stream is then injected into the general ledger processing module of the enterprise's internal resource planning system to drive the synchronous update operation of the general ledger and subsidiary ledger.

2. The financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting as described in claim 1, characterized in that, The acquisition of raw business event streams output from multiple external business platform data sources associated with the enterprise's transaction activities, and a set of static financial rule information extracted from the enterprise's internal resource planning system, includes: The system accesses the order status change push service provided by the e-commerce transaction platform data source, subscribes to the order status change topics published by the e-commerce transaction platform data source through the order status change push service, and pulls order status change events in real time from the order status change topics. The event body of each order status change event encapsulates a globally unique identifier string for the order, an order status change path description string, a set of unit codes for the inventory quantity of the traded goods, a set of sets ... The system accesses the invoice status change push service provided by the data source of the electronic invoice service platform, subscribes to the invoice status change topics published by the data source of the electronic invoice service platform through the invoice status change push service, and pulls invoice status change events in real time from the invoice status change topics. The event body of each invoice status change event encapsulates the globally unique invoice identifier string, invoice type descriptor, invoice amount, invoice tax amount, seller taxpayer identification number string, buyer taxpayer identification number string, and the set of globally unique order identifier strings associated with the globally unique invoice identifier string. The system accesses the fund transfer status change push service provided by the bank payment and settlement platform data source, subscribes to the fund transfer status change topics published by the bank payment and settlement platform data source through the fund transfer status change push service, and pulls fund transfer status change events in real time from the fund transfer status change topics. The event body of each fund transfer status change event encapsulates the fund transfer transaction serial number string, the payer's bank account string, the payee's bank account string, the fund transfer amount value, the fund transfer completion timestamp, the fund transfer status descriptor, and the globally unique identifier string of the order or the globally unique identifier string of the invoice associated with the fund transfer behavior. The real-time retrieved order status change events, invoice status change events, and fund transfer status change events are written into different topic storage partitions of the distributed message queue system according to the order of the event timestamps, forming a continuously flowing stream of original business events. The pre-configured subject structure tree table is read from the database of the enterprise's internal resource planning system. The subject structure tree table includes a subject code primary key field, a subject full Chinese name field, a subject level numeric field, a parent subject code field, a subject category distinction field, and a subject balance direction indicator field. The read subject structure tree table is used as the accounting subject table structure information. The pre-configured tax jurisdiction area table is read from the database of the enterprise's internal resource planning system. The tax jurisdiction area table includes a tax jurisdiction area code field, a jurisdiction area name field, an applicable tax rate value field, a tax base definition text field, and a tax liability occurrence time determination rule text field. The read tax jurisdiction area table is used as tax processing rule information.

3. The financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting as described in claim 1, characterized in that, The process involves mining inter-event correlation clues for order status transition events, invoice status transition events, and fund transfer status transition events in the original business event flow. Based on the mined correlation clues, order status transition events, invoice status transition events, and fund transfer status transition events belonging to the same transaction context are aggregated across events to generate a fused transaction description structure, including: Order status transition events are sequentially retrieved from the order status transition topic storage partition of the distributed message queue system. The event body of the order status transition event is parsed. The globally unique identifier string of the order, the unit code set of the inventory quantity of the traded goods, the set of the quantity of goods traded, the set of the unit price of the goods traded, the buyer member identifier string and the seller store identifier string are read from the event body. The read information is combined into an order dimension information group. The system sequentially pulls out bill status transition events from the bill status transition topic storage partition of the distributed message queue system, parses the event body of the bill status transition event, and reads the globally unique invoice identifier string, invoice type descriptor, invoice tax amount value and the associated globally unique order identifier string set from the event body. The read information is then combined into a bill dimension information group. The fund transfer status change events are sequentially retrieved from the fund transfer status change topic storage partition of the distributed message queue system. The event body of the fund transfer status change event is parsed. The fund transfer transaction serial number string, the payer's bank account string, the payee's bank account string, the fund transfer amount, the fund transfer completion timestamp, and the associated globally unique identifier string of the order or the globally unique identifier string of the invoice are read from the event body. The read information is combined into a fund dimension information group. Extract the globally unique identifier string of the order from the order dimension information group as the first aggregation clue, extract each globally unique identifier string of the order from the set of globally unique identifier strings of the associated order in the bill dimension information group as the second aggregation clue, and extract the globally unique identifier string of the order or the globally unique identifier string of the invoice from the fund dimension information group as the third aggregation clue. Perform string equivalence comparison on each globally unique identifier string of the first aggregated clue, the second aggregated clue, and the third aggregated clue. Collect the order dimension information group, bill dimension information group, and fund dimension information group corresponding to the globally unique identifier string of the same order that are successfully matched into the same temporary collection and storage area. Within the temporary aggregation and storage area, the aggregated order dimension information group is written into the business information storage slot of the preset structure template, the aggregated invoice dimension information group is written into the invoice information storage slot of the preset structure template, and the aggregated funds dimension information group is written into the funds information storage slot of the preset structure template. The write status of the business information storage slot, bill information storage slot, and fund information storage slot of the preset structure template is continuously monitored. When all three slots are filled with non-empty information, the state of the preset structure template is marked as information complete, and the preset structure template in information complete state is output as a fusion transaction description structure.

4. The financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting as described in claim 1, characterized in that, The embedded accounting rule matcher is invoked to decompose the accounting elements of the fused transaction description structure. From the fused transaction description structure, revenue recognition element group, cost collection element group, tax calculation element group, and accounts receivable / payable tracking element group are sequentially separated. Each separated element group is then mapped and bound to the account chart structure information and tax processing rule information in the static financial rule information set, generating a multi-dimensional accounting instruction set corresponding to the fused transaction description structure, including: The fusion transaction description structure is input into the input terminal of the embedded accounting rule matcher, which is internally configured with a business direction discrimination channel, a revenue element stripping channel, a cost element stripping channel, a tax element stripping channel, and a receivables and payables element stripping channel. The business direction discrimination channel scans the business information storage slots in the integrated transaction description structure, reads the buyer member identifier string and the seller store identifier string from the business information storage slots, compares the buyer member identifier string with the preset internal entity identifier library to generate a buyer identity tag, compares the seller store identifier string with the preset internal entity identifier library to generate a seller identity tag, and identifies the transaction direction features based on the combination of the buyer identity tag and the seller identity tag. The identified transaction direction features are input into the revenue element stripping channel. The revenue element stripping channel determines whether to trigger a revenue recognition operation based on the transaction direction features. When a revenue recognition operation is triggered, the channel reads the total order amount including tax from the business information storage slot of the integrated transaction description structure and reads the invoice tax amount from the bill information storage slot of the integrated transaction description structure. The total order amount including tax is subtracted from the invoice tax amount to obtain the revenue amount to be recognized. The revenue amount to be recognized is then associated with the transaction direction features and encapsulated to generate a revenue recognition element group. The identified transaction direction features are input into the cost element stripping channel. The cost element stripping channel determines whether to trigger a cost aggregation operation based on the transaction direction features. When it is determined that a cost aggregation operation has been triggered, the channel reads the set of commodity transaction quantity and the set of commodity transaction unit price from the business information storage slot of the fused transaction item description structure. The channel performs item-by-item multiplication on the set of commodity transaction quantity and the set of commodity transaction unit price, and then accumulates them to generate the cost amount to be aggregated. The cost amount to be aggregated is then associated with the transaction direction features and encapsulated to generate a cost aggregation element group. The identified transaction direction features are input into the tax element stripping channel. The tax element stripping channel determines whether to trigger the tax calculation operation based on the transaction direction features. When it is determined that the tax calculation operation is triggered, the channel reads the invoice type descriptor and the invoice tax amount from the invoice information storage slot of the fused transaction description structure, and associates and encapsulates the invoice type descriptor and the invoice tax amount to generate a tax calculation element group. The identified transaction direction features are input into the transaction element stripping channel. The transaction element stripping channel determines whether to trigger a transaction tracking operation based on the transaction direction features. When it is determined that a transaction tracking operation has been triggered, the channel reads the payer's bank account string, the payee's bank account string, and the fund transfer completion timestamp from the fund information storage slot of the fused transaction description structure. The payer's bank account string, the payee's bank account string, and the fund transfer completion timestamp are associated and encapsulated to generate a transaction tracking element group. The accounting chart structure information is read from the static financial rules information set. Based on the transaction direction characteristics carried in the revenue recognition element group, the corresponding revenue category code is located in the accounting chart structure information. The located revenue category code is bound to the revenue recognition element group to generate a revenue recognition sub-instruction carrying the revenue category code. The accounting chart structure information is read from the static financial rule information set. Based on the transaction direction characteristics carried in the cost collection element group, the corresponding cost account code is located in the accounting chart structure information. The located cost account code is bound to the cost collection element group to generate a cost collection sub-instruction carrying the cost account code. Tax processing rule information is read from the static financial rule information set. Based on the invoice type descriptor carried in the tax calculation element group, the corresponding tax jurisdiction code and applicable tax rate value are located in the tax processing rule information. The located tax jurisdiction code and applicable tax rate value are bound to the tax calculation element group to generate a tax calculation sub-instruction carrying a tax jurisdiction identifier. The accounting chart structure information is read from the static financial rule information set. The corresponding account code is located in the accounting chart structure information according to the payer's bank account string or payee's bank account string carried in the account tracking element group. The located account code is bound to the account tracking element group to generate an account tracking sub-instruction carrying the account code. The revenue recognition sub-instruction, the cost collection sub-instruction, the tax calculation sub-instruction, and the transaction tracking sub-instruction are combined to generate a multi-dimensional accounting instruction set corresponding to the integrated transaction description structure.

5. The financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting as described in claim 4, characterized in that, The process involves scanning the business information storage slots in the fused transaction description structure via the business direction discrimination channel, retrieving the buyer member identifier string and seller store identifier string from the business information storage slots, comparing the buyer member identifier string with a preset internal entity identifier database to generate a buyer identity tag, comparing the seller store identifier string with the preset internal entity identifier database to generate a seller identity tag, and identifying transaction direction features based on the combination of the buyer identity tag and the seller identity tag, including: The business direction determination channel sequentially reads the buyer member identifier string and the seller store identifier string from the business information storage slot of the integrated transaction description structure; Each read buyer member identifier string is matched against the internal entity identifier strings stored in the preset internal entity identifier library. If the buyer member identifier string matches any internal entity identifier string in the internal entity identifier library, an internal entity buyer tag is generated for the buyer member identifier string. If the buyer member identifier string does not match any internal entity identifier string in the internal entity identifier library, an external entity buyer tag is generated for the buyer member identifier string. Each read seller store identifier string is matched against the internal entity identifier strings stored in the preset internal entity identifier library. If the seller store identifier string matches any internal entity identifier string in the internal entity identifier library, an internal entity seller tag is generated for the seller store identifier string. If the seller store identifier string does not match any internal entity identifier string in the internal entity identifier library, an external entity seller tag is generated for the seller store identifier string. The generated buyer identity tag and seller identity tag are combined and paired. If the buyer identity tag is an external entity buyer tag and the seller identity tag is an internal entity seller tag, then the transaction direction feature corresponding to the current fused transaction description structure is identified as the external sales revenue type direction feature. If the buyer identity label is an internal entity buyer label and the seller identity label is an external entity seller label, then the transaction direction feature corresponding to the current fusion transaction description structure is identified as the external procurement cost type direction feature; If the buyer identity label is an internal entity buyer label and the seller identity label is an internal entity seller label, then the transaction direction feature corresponding to the current fusion transaction description structure is identified as an internal circulation and settlement type direction feature. If the buyer identity label is an external entity buyer label and the seller identity label is an external entity seller label, then the transaction direction feature corresponding to the current fused transaction description structure is identified as an external market transaction direction feature; The identified transaction direction features are used as the output of the business direction discrimination channel and are respectively transmitted to the input of the revenue element stripping channel, the cost element stripping channel, the tax element stripping channel, and the intercompany element stripping channel.

6. The financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting as described in claim 4, characterized in that, The identified transaction direction features are input into the revenue element stripping channel. The revenue element stripping channel determines whether a revenue recognition operation is triggered based on the transaction direction features. If a revenue recognition operation is triggered, the channel reads the total order amount (including tax) from the business information storage slot of the fused transaction description structure as the revenue amount to be recognized, and associates and encapsulates the revenue amount to be recognized with the transaction direction features to generate a revenue recognition element group, including: The revenue element stripping channel receives the transaction direction features transmitted by the business direction discrimination channel, and compares the received transaction direction features with a preset revenue trigger direction feature set, which includes external sales revenue type direction features and external market transaction type direction features. If the received transaction direction feature matches any of the preset revenue trigger direction feature sets, then the current fused transaction description structure is determined to trigger the revenue recognition operation, and the revenue amount positioning process is initiated. If the received transaction direction feature does not match any of the preset revenue trigger direction feature sets, it is determined that the current fused transaction description structure does not trigger the revenue recognition operation, the revenue element stripping process is terminated and an empty revenue recognition element group identifier is returned. After determining that the revenue recognition operation has been triggered, the revenue element stripping channel reads the total order amount including tax from the business information storage slot of the integrated transaction description structure and reads the invoice tax amount from the bill information storage slot of the integrated transaction description structure. The total order amount including tax is subtracted from the invoice tax amount, and the difference is taken as the revenue amount to be recognized. The extracted revenue amount to be recognized is associated and combined with the received transaction direction features to generate a revenue recognition element group containing revenue amount values ​​and direction feature labels. The revenue recognition element group is then passed to the stage of binding with the accounting chart structure information.

7. The financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting as described in claim 4, characterized in that, The identified transaction direction features are input into the cost element stripping channel. The cost element stripping channel determines whether a cost aggregation operation is triggered based on the transaction direction features. If a cost aggregation operation is triggered, it reads the product transaction quantity set and product transaction unit price set from the business information storage slot of the fused transaction item description structure. It performs item-by-item multiplication on the product transaction quantity set and the product transaction unit price set, then accumulates them to generate the cost amount to be aggregated. Finally, it associates and encapsulates the cost amount to be aggregated with the transaction direction features to generate a cost aggregation element group, including: The cost element stripping channel receives the transaction direction features transmitted by the business direction discrimination channel, and compares the received transaction direction features with a preset cost trigger direction feature set. The preset cost trigger direction feature set includes external procurement cost type direction features and internal circulation settlement type direction features. If the received transaction direction feature matches any of the preset cost trigger direction feature sets, then the current fused transaction description structure is determined to trigger the cost aggregation operation, and the cost amount positioning process is initiated. If the received transaction direction feature does not match any of the preset cost trigger direction feature sets, it is determined that the current fused transaction description structure does not trigger the cost aggregation operation, the cost element stripping process is terminated and an empty cost aggregation element group identifier is returned. After determining that the cost aggregation operation has been triggered, the cost element stripping channel sequentially reads the set of commodity transaction quantity and the set of commodity transaction unit price from the business information storage slot of the fused transaction description structure. Multiply the transaction quantity of each commodity in the transaction quantity set with the transaction unit price of the corresponding commodity in the transaction unit price set to generate the median cost amount of each transaction commodity; The median cost amount of all generated transaction goods is summed, and the summation result is used as the cost amount to be collected. The generated cost amount to be collected is associated and combined with the received transaction direction features to generate a cost collection element group containing cost amount values ​​and direction feature labels, and the cost collection element group is then passed to the stage of binding with the chart of accounts structure information.

8. The financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting as described in claim 1, characterized in that, The process of merging the posting direction indication information and account hierarchy path information carried in the multi-dimensional accounting instruction set to generate a general ledger update instruction stream containing general ledger account summary information and subsidiary ledger account occurrence information, and injecting the general ledger update instruction stream into the general ledger processing module of the enterprise's internal resource planning system to drive the synchronous update operation of the general ledger and subsidiary ledgers, includes: The multidimensional accounting instruction set is analyzed, and the following sub-instructions are separated from the multidimensional accounting instruction set: revenue recognition sub-instruction carrying revenue account code, cost collection sub-instruction carrying cost account code, tax calculation sub-instruction carrying tax jurisdiction identifier, and transaction tracking sub-instruction carrying transaction account code. Extract the revenue account code and the amount of revenue to be recognized from the revenue recognition sub-instruction; extract the cost account code and the amount of cost to be collected from the cost collection sub-instruction; extract the tax jurisdiction identifier and the amount of tax payable from the tax calculation sub-instruction; extract the receivable / payable account code and the counterparty identifier from the receivable / payable tracking sub-instruction. Based on the extracted revenue account code, locate the corresponding revenue general ledger account hierarchical path and revenue subsidiary ledger account code in the chart of accounts structure information, associate the revenue amount to be identified with the located revenue general ledger account hierarchical path and revenue subsidiary ledger account code, and generate a revenue accounting unit; Based on the extracted cost account codes, locate the corresponding cost general ledger account hierarchical path and cost subsidiary ledger account codes in the chart of accounts structure information, associate the cost amount to be aggregated with the located cost general ledger account hierarchical path and cost subsidiary ledger account codes, and generate cost accounting units; Based on the extracted tax jurisdiction identifier, locate the corresponding tax payable account code in the tax processing rule information, associate the tax payable amount with the located tax payable account code, and generate a tax-related accounting unit. Based on the extracted account codes, locate the corresponding general ledger account hierarchical path and subsidiary ledger account codes in the chart of accounts structure information, associate the counterparty identifier with the located general ledger account hierarchical path and subsidiary ledger account codes, and generate an account posting unit. Collect the generated revenue accounting units, cost accounting units, tax accounting units, and accounts receivable / payable accounting units. Group and merge all accounting units according to the general ledger account hierarchy path. Accumulate and summarize the transaction amounts of all accounting units under the same general ledger account hierarchy path to generate the current period transaction summary value corresponding to each general ledger account hierarchy path as the general ledger account summary information. All accounting units are grouped and merged according to the subsidiary ledger account code. Multiple transactions under the same subsidiary ledger account code are arranged into a chronological transaction sequence according to the order in which the accounting units are generated. The chronological transaction sequence is used as the subsidiary ledger account transaction information. The generated general ledger account summary information and subsidiary ledger account occurrence information are encapsulated into a general ledger update instruction stream in a structured data format. The general ledger update instruction stream is transmitted to the general ledger processing module through the general ledger write interface opened by the enterprise internal resource planning system. This triggers the general ledger processing module to update the account balances in the general ledger balance sheet according to the general ledger account summary information, and to append the corresponding chronological occurrence record rows to the subsidiary ledger according to the subsidiary ledger account occurrence information.

9. A financial automation system based on cross-platform business and financial data aggregation and AI intelligent accounting, characterized in that, include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting as described in any one of claims 1 to 8 by executing the machine-executable instructions.

10. A computer program product, characterized in that, The computer program product includes machine-executable instructions stored in a computer-readable storage medium. The processor of the financial automation system based on cross-platform business and financial data aggregation and AI intelligent accounting reads the machine-executable instructions from the computer-readable storage medium and executes the machine-executable instructions, causing the financial automation system based on cross-platform business and financial data aggregation and AI intelligent accounting to perform the financial automation method based on cross-platform business and financial data aggregation and AI intelligent accounting as described in any one of claims 1 to 8.

Images