Logistics billing engine system and method

Abstract

The present application provides a logistics billing engine system and method, which relates to the field of logistics and transportation technology. The method includes extracting business fields and measurement fields from billing documents, matching billing rules to generate a fee calculation plan, and performing calculations on the measurement fields to obtain billing results. The billing results and related document information are aggregated to form a settlement statement, and multiple settlement statements are aggregated according to pre-set merging rules to form an invoice. The settlement statement can also be formed by constructing an adjacency matrix and performing a graph search on its non-zero correlation, and automatically merging multiple billing results that meet the threshold conditions. Before merging, individual anomaly detection is performed on the billing results, and the adjacency matrix is constructed after excluding abnormal orders; after the merger is completed, group anomaly detection is performed on the entire group of orders, and if an anomaly is triggered, it is split or isolated. The present application can improve the merging efficiency and anomaly prevention and control in large-scale order scenarios while maintaining billing accuracy.

Description

Technical Field

[0001] The present application relates to the field of logistics and transportation technology, and more specifically, to a logistics billing engine system and method. Background Art

[0002] Existing logistics billing systems typically calculate costs for transport orders, shipping documents, and other items using fixed rules. Once calculated, settlement documents are aggregated and invoices are consolidated manually or semi-automatically. However, these traditional solutions often rely on simple field matching or single-factor judgment, making it difficult to accommodate flexible rates across different contracts and business scenarios. Furthermore, with the continued expansion of logistics operations and the diversification of order types, relying solely on common field equality or a small number of rules makes it difficult to automatically identify and consolidate large numbers of similar orders or duplicate business items. Furthermore, individual orders may pose potential anomaly risks due to data entry errors, carrier anomalies, or other reasons. Traditional systems often require manual screening to avoid miscalculations or duplicate billing, a time-consuming and unsystematic approach. Existing methods, in particular, lack robust anomaly detection mechanisms and multi-dimensional automatic consolidation capabilities when dealing with large order volumes, multiple dimensions, or cross-organizational collaboration. This makes it difficult to meet the higher demands of the modern logistics industry for billing accuracy and settlement efficiency. Summary of the Invention

[0003] In response to the deficiencies of the existing technology, this application provides a logistics billing engine system and method.

[0004] In a first aspect, the present application provides a logistics billing engine method, including:

[0005] Obtaining a billing document, and extracting a business field and a metering field from the billing document;

[0006] According to the business field and the metering field, matching the pre-configured billing rules, generating a corresponding fee calculation plan;

[0007] Based on the fee calculation scheme, the meter field is operated to obtain a billing result;

[0008] The billing results and related document information are aggregated, multiple billing result groups are constructed based on the association of business fields, and corresponding settlement documents are generated according to each billing result group;

[0009] Aggregate multiple settlement documents and form a bill according to pre-set consolidation rules;

[0010] The forming of the settlement statement further includes: assigning a unique identifier to each billing result, and constructing an adjacency matrix based on matching conditions in the service fields between the billing results; performing a graph search for non-zero associations in the adjacency matrix, and merging multiple billing results whose associations meet a preset threshold to generate a single settlement statement;

[0011] Before the merging to generate a single settlement statement, it also includes: performing individual anomaly detection on each of the billing results, and in response to the billing result meeting the anomaly judgment condition, marking it as an anomaly and excluding it from the construction of the adjacency matrix; only constructing the adjacency matrix and performing graph search for the billing results that are not marked as abnormal.

[0012] As an optional implementation manner, the matching of pre-configured charging rules includes:

[0013] Performing conditional judgment on the service field to determine a rate field interval corresponding to the service field;

[0014] According to the rate field interval, the meter field is segmented and a segmented rate is obtained;

[0015] The fee calculation scheme is generated based on the segmented rates.

[0016] As an optional implementation, when generating the fee calculation scheme, the following steps are further included:

[0017] Set a minimum billing amount and a maximum billing amount. If the calculated billing result is less than the minimum billing amount, the minimum billing amount will be used; if it is greater than the maximum billing amount, the maximum billing amount will be used;

[0018] Set the minimum billing quantity and the maximum billing quantity. When the calculated quantity is less than the minimum billing quantity, the minimum billing quantity is used. When the calculated quantity is greater than the maximum billing quantity, the maximum billing quantity is used.

[0019] As an optional implementation, the billing results and related document information are aggregated, multiple billing result groups are constructed based on the association of business fields, and a corresponding settlement document is generated according to each billing result group, including:

[0020] Filtering the billing results according to pre-set filtering conditions, wherein the filtering conditions include at least one of a carrier, a shipper, and a transportation type;

[0021] In response to the fact that the order date, transportation route, consignee and delivery location information are the same, multiple billing results that meet the filtering conditions are merged to generate a single settlement statement.

[0022] As an optional implementation, aggregating multiple settlement documents and forming an invoice according to a pre-set merging rule includes:

[0023] Filtering the settlement documents according to pre-set bill generation filtering conditions, wherein the bill generation filtering conditions include at least one of customer identification, billing cycle, or organization dimension;

[0024] In response to satisfying the bill generation filtering condition, aggregating and merging the plurality of single settlement bills;

[0025] Combine consolidated statement information into a single bill.

[0026] As an optional implementation manner, after merging multiple billing result groups using the adjacency matrix and generating a single settlement statement, the method further includes:

[0027] Performing group anomaly detection on each of the billing result groups, and in response to the billing result group meeting the group anomaly determination condition, marking the billing result group as abnormal pending review and performing splitting or isolation processing;

[0028] In response to determining that no group abnormality exists, a single settlement statement corresponding to the billing result group is output.

[0029] As an optional implementation, the aggregating multiple settlement documents and forming an invoice according to a pre-set merging rule further includes:

[0030] Create graph nodes in the knowledge graph database to represent business entities such as settlement orders, orders, carriers, transportation routes, and billing cycles, as well as edges to represent dependencies or associations between business entities.

[0031] Writing the key field information of the settlement form into the knowledge graph database to form a graph data structure for bill merging;

[0032] Performing reasoning operations on the settlement order nodes and their associated relationships in the knowledge graph database based on pre-configured business rules or an inference engine to automatically identify a set of settlement order nodes that meet bill consolidation conditions;

[0033] The set of settlement order nodes identified by the reasoning operation is linked to the adjacency matrix or the anomaly detection module for processing. When it is determined that no anomaly exists, the merged bill is output. If it is determined that an anomaly exists, the relevant settlement orders are split or isolated to dynamically aggregate the bills.

[0034] As an optional implementation, the aggregating multiple settlement documents and forming an invoice according to a pre-set merging rule further includes:

[0035] Reading the vectorized field information generated for each order from a storage medium, and performing batch similarity calculation on the vectorized field information to form an adjacency matrix for the partial blocks, wherein the adjacency matrix records non-zero similarities between order pairs;

[0036] When importing the adjacency matrix into the knowledge graph database, a corresponding graph node is created or updated for each order, and a relationship edge is established or updated between the graph nodes based on the similarity result in the adjacency matrix, and the relationship edge carries a similarity vector or a correlation attribute;

[0037] Generate a supernode for a set of orders with a similarity greater than a preset similarity threshold and the same field value, treat the supernode as a single node object in the knowledge graph database, and attach the differentiated fields of each order in the order set to it in the form of an additional vector;

[0038] When performing bill aggregation, whether each order meets the merging conditions is determined based on the super node and its additional vector, and reasoning is performed in combination with cross-entity information. In response to meeting the bill merging conditions, a corresponding bill node is created in the knowledge graph database and associated with the relevant order node.

[0039] In a second aspect, this application provides a logistics billing engine system, including:

[0040] The acquisition module obtains the billing document and extracts the business field and the metering field from the billing document;

[0041] A first calculation module, matching pre-configured billing rules according to the service field and the metering field, and generating a corresponding fee calculation plan;

[0042] A second calculation module, based on the fee calculation scheme, performs calculations on the meter field to obtain a billing result;

[0043] The settlement module collects the billing results and related document information, constructs multiple billing result groups based on the association of business fields, and generates corresponding settlement documents based on each billing result group;

[0044] The generation module aggregates multiple settlement documents and forms an invoice based on pre-set merging rules.

[0045] Compared with the existing technology, the present application can significantly improve the flexibility and accuracy of automatically merging settlement orders by introducing an adjacency matrix and multi-stage anomaly detection after obtaining the billing results. First, by assigning a unique identifier to each billing result and constructing an adjacency matrix based on the business field, graph search or clustering is performed on the results that meet a certain correlation threshold between each other, which can efficiently find "partially similar" or "multi-dimensionally similar" orders for merging, reducing manual judgment. Secondly, individual anomalies are eliminated before merging, and group anomaly detection is performed after merging, which can effectively intercept single or entire groups of potential anomalies and provide security for subsequent bill aggregation. Finally, through a variety of optional implementation methods such as minimum / maximum billing limits and segmented rates, the refinement and controllability of the cost calculation process are further enhanced, and the applicability and computational efficiency of the logistics billing engine in different business scenarios are greatly improved, avoiding problems such as mismerging, missed merging, and untimely processing of abnormal orders caused by simple rules in traditional systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 A flow chart of the logistics billing engine method provided in an embodiment of the present application;

[0047] Figure 2 A schematic diagram of a billing system provided in an embodiment of the present application;

[0048] Figure 3 A flow chart of a group anomaly detection method provided in an embodiment of the present application;

[0049] Figure 4 A schematic diagram of the logistics billing engine system provided in an embodiment of the present application.

[0050] Reference numerals: 10, acquisition module; 20, first calculation module; 30, second calculation module; 40, settlement module; 50, generation module. DETAILED DESCRIPTION

[0051] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments.

[0052] See also Figure 1 FIG. 1 is a flow chart of a logistics billing engine method provided in an embodiment of the present application, wherein the method includes steps S101 to S105, wherein:

[0053] S101: Obtain a billing document, and extract a business field and a metering field from the billing document;

[0054] S102: According to the service field and the metering field, a pre-configured charging rule is matched to generate a corresponding fee calculation plan;

[0055] S103: Based on the fee calculation scheme, the meter field is operated to obtain a billing result;

[0056] S104: The billing results and related document information are aggregated, multiple billing result groups are constructed based on the association of business fields, and corresponding settlement documents are generated according to each billing result group;

[0057] S105: According to the pre-set merging rules, multiple settlement orders are aggregated and a bill is formed.

[0058] In specific implementations, billing documents, such as shipping orders or shipping notes, are first retrieved from the business system. To facilitate subsequent fee calculations, the business and measurement fields are extracted from these billing documents. Business fields typically reflect billing conditions (such as shipping routes, vehicle types, carriers, and shippers), while measurement fields are used for specific numerical calculations (such as weight, volume, quantity, and mileage). By categorizing these fields, corresponding billing rules can be matched to specific field types in subsequent steps.

[0059] When matching pre-configured billing rules, the corresponding rate range can be retrieved or determined based on the value of the service field, or the meter field can be segmented based on the combination of service fields to generate a fee calculation plan. This fee calculation plan includes information such as the calculation method, rate reference, and restrictions for different meter fields. Subsequently, based on the fee calculation plan, the aforementioned meter fields are calculated to obtain the billing result. The calculation process may include multiplication with the rate, addition, capping, and floor value processing.

[0060] After receiving the billing results, the system aggregates them with the corresponding invoice information to create a settlement statement. This statement can be considered a relatively complete record of expense details, encompassing all relevant fields and calculations, providing a basis for subsequent consolidation or financial reconciliation. Finally, based on pre-defined consolidation rules, multiple settlement statements that meet the requirements are aggregated and an invoice is generated.

[0061] In a specific implementation, the consolidation rules can include organizational dimensions, billing cycles, or other filtering conditions to categorize and summarize settlement documents.

[0062] Through the above steps, a rule-based logistics billing engine method can be implemented to meet the cost calculation needs in various business scenarios and simplify the subsequent settlement process.

[0063] As an optional implementation manner, the matching of pre-configured charging rules includes:

[0064] Performing conditional judgment on the service field to determine a rate field interval corresponding to the service field;

[0065] According to the rate field interval, the meter field is segmented and a segmented rate is obtained;

[0066] The fee calculation scheme is generated based on the segmented rates.

[0067] In specific implementations, when making conditional judgments on business fields, the corresponding rate field range can be determined based on the transportation routes, vehicle types, shippers or other business-related attributes in different business scenarios.

[0068] Specifically, the system first searches for values in the business field. For example, if the transport route is within a specific area, it matches the corresponding rate range table; if the vehicle type is a large vehicle, it matches another rate range table. This matching process can refine the subsequent segmentation rules for the meter field.

[0069] The measurement field is then segmented based on the matching rate field intervals. For example, for the weight field, 0 to 10 tons could be defined as the first rate band, 10 to 20 tons as the second rate band, and weights exceeding 20 tons would enter the third rate band. Each rate band corresponds to one or more rate calculation parameters. By segmenting the measurement field, the system can generate segmented rates, which can be used to distinguish between fee levels within different weight ranges or other numerical ranges.

[0070] Based on the segmented rates, a fee calculation scheme is further generated. The fee calculation scheme may include the rate values used for the meter field in each interval, the cumulative calculation method, or other additional rules (such as minimum fee, maximum fee limit, etc.).

[0071] In this way, the solution is ultimately output to the subsequent billing steps for calculating charges for specific business orders or shipping orders, enabling the flexible and accurate application of corresponding segmented rates under different business field conditions, thus achieving multi-dimensional and refined billing processing.

[0072] As an optional implementation, when generating the fee calculation scheme, the following steps are further included:

[0073] Set a minimum billing amount and a maximum billing amount. If the calculated billing result is less than the minimum billing amount, the minimum billing amount will be used; if the calculated billing result is greater than the maximum billing amount, the maximum billing amount will be used.

[0074] Set the minimum billing quantity and the maximum billing quantity. When the calculated quantity is less than the minimum billing quantity, the minimum billing quantity is used. When the calculated quantity is greater than the maximum billing quantity, the maximum billing quantity is used.

[0075] In practice, to better control the upper and lower limits of costs or quantities when generating the fee calculation plan, the system can first define a minimum billing amount and a maximum billing amount. After calculating the meter field, if the calculated billing result is less than the minimum billing amount, the billing result is adjusted to the minimum billing amount; if the calculated billing result is greater than the maximum billing amount, the billing result is adjusted to the maximum billing amount. This approach effectively avoids extreme cases of under- or over-charging during the billing process.

[0076] The system also controls the minimum and maximum billable quantities involved in billing. For example, if the quantity calculated based on the meter field or tiered rate is less than the minimum billable quantity, the result is adjusted to the minimum billable quantity; if it is greater than the maximum billable quantity, it is adjusted to the maximum billable quantity. This ensures that the quantity value remains within a reasonable range during the calculation process, avoiding abnormal deviations in order or shipment volume at the billing end.

[0077] The above minimum billing amount, maximum billing amount, minimum billing quantity, and maximum billing quantity can be configured according to fixed thresholds or dynamically adjusted based on business scenarios or seasonal changes. This allows for timely corrections to extreme billing results without affecting normal billing logic, improving the stability and rationality of overall billing. This implementation, combined with the basic segmented rate, allows the system to generate cost calculation plans, standardizing billing according to interval rates while also meeting more diverse business needs by effectively limiting the upper and lower limits of costs and quantities.

[0078] As an optional implementation, the billing results and related document information are aggregated, multiple billing result groups are constructed based on the association of business fields, and a corresponding settlement document is generated according to each billing result group, including:

[0079] Filtering the billing results according to pre-set filtering conditions, wherein the filtering conditions include at least one of a carrier, a shipper, and a transportation type;

[0080] In response to the fact that the order date, transportation route, consignee and delivery location information are the same, multiple billing results that meet the filtering conditions are merged to generate a single settlement statement.

[0081] In practice, when compiling billing results and related document information into a settlement statement, the system first filters the billing results according to pre-defined filtering criteria. These filtering criteria can include business dimensions such as carrier, shipper, and transport type. Specifically, the system reads the carrier, shipper, and transport type fields corresponding to each billing result and marks the results that meet the specified criteria as mergeable objects, thereby providing preliminary grouping for subsequent merging operations.

[0082] Next, the system checks fields such as order date, shipping route, consignee, and destination for these mergeable objects. If multiple billing results have identical values for these fields, they are merged to create a single invoice. This merge operation aggregates or consolidates key data such as cost details, quantity, and weight across the relevant billing results, centrally recording them in the invoice. This reduces the number of duplicate invoices and improves efficiency during subsequent settlement and reconciliation. Once generated, the invoice can be used for subsequent processing steps such as bill aggregation and financial reconciliation.

[0083] In this way, through this screening and merging mechanism based on multi-dimensional business fields, the system can simplify the settlement invoice management process while maintaining billing accuracy.

[0084] As an optional implementation, aggregating multiple settlement documents and forming an invoice according to a pre-set merging rule includes:

[0085] Filtering the settlement documents according to pre-set bill generation filtering conditions, wherein the bill generation filtering conditions include at least one of customer identification, billing cycle, or organization dimension;

[0086] In response to satisfying the bill generation filtering condition, aggregating and merging the plurality of single settlement bills;

[0087] Combine consolidated statement information into a single bill.

[0088] In practice, after a single settlement document is generated, the system will further filter all settlement documents based on pre-defined criteria. These criteria may include business factors such as customer ID, billing cycle, or organizational dimension. For example, the system may search for all settlement documents generated within a pre-defined billing cycle (e.g., monthly, quarterly, etc.). It may also aggregate settlement documents generated for the same customer at different times based on customer ID, or centrally process settlement documents belonging to the same business department based on organizational dimension.

[0089] When the invoice generation filter conditions are met, the system aggregates and merges multiple single settlement documents that meet the conditions. Specifically, the system can first verify the merging rules of these settlement documents to be merged, such as checking whether they are from the same customer or the same billing cycle, or whether they meet specific revenue or expense accounting requirements. If all conditions are met, the corresponding expense details, quantities, time periods, and related field information are summarized at the invoice level. This merging operation can simplify the subsequent financial reconciliation or audit process and avoid the occurrence of too many scattered settlement documents for the same customer or the same billing cycle.

[0090] After consolidation, the system aggregates the resulting billing information into a single invoice. This invoice can include all consolidated charges, aggregated quantities, and other additional information specific to the customer ID or billing period, facilitating subsequent audits, invoicing, and reconciliation.

[0091] In this way, by collecting and merging multiple settlement statements, on the one hand, the efficiency of bill management can be improved, and on the other hand, the consistency and integrity of bill data in the vertical and horizontal directions can be guaranteed, providing data support for subsequent financial processes.

[0092] As an optional implementation, the step of aggregating the billing results and related document information to form a settlement statement further includes:

[0093] Assign a unique identifier to each billing result and build an adjacency matrix based on the matching of business fields between billing results;

[0094] A graph search is performed on the non-zero associations in the adjacency matrix, and multiple billing results whose associations meet a preset threshold are merged to generate a single settlement statement.

[0095] In specific implementations, in order to more flexibly aggregate billing results and related document information into a single settlement form, the system can use an adjacency matrix to represent the correlation between different billing results and automatically identify billing results that can be merged through graph search or clustering methods. Specifically, the following steps may be included:

[0096] First, a unique identifier is assigned to each billing result, and its key business fields are recorded separately. The key business fields may include transportation routes, carriers, consignees, shippers, vehicle models, and transportation time. Next, for any two billing results, the system reads the values of their business fields and calculates the degree of association, such as whether their shipping and receiving locations are continuous, whether the transportation time overlaps, whether the carriers are the same, or whether the vehicle models are compatible. If the two billing results meet the preset conditions in at least one or more business fields, a non-zero value is written in the corresponding position of the adjacency matrix to indicate that the two have the potential to be merged; if the conditions are not met, the value is assigned to zero.

[0097] After completing the construction of the adjacency matrix, the system can perform graph search or clustering based on a pre-set threshold. Specifically, the system traverses each non-zero element in the adjacency matrix. If its value is greater than or equal to the threshold, it determines that the corresponding two billing results have a high degree of correlation and are mergeable objects. Through depth-first search (DFS), breadth-first search (BFS) or other clustering algorithms, the system can group several billing results with a sufficiently high degree of correlation into the same group. When all billing results in a group have been identified, the system merges the information of all billing results in the group to form a single settlement statement.

[0098] During the settlement form generation process, the system will also merge the relevant cost details of the billing results within the group, such as deduplicating repeated fields, accumulating the quantity, weight or other cumulative fields, and registering a unified settlement time or settlement identifier in the settlement form.

[0099] For example, a unique identifier is assigned to each pending order: basic information and billing results of each order are read, and the shipping location, shipping location, carrier, transportation time, and other business fields that affect the merging are recorded respectively;

[0100] Construct an adjacency matrix: Create one for N orders in the system Matrix A. If there is a condition that orders i and j can be merged, then Write the corresponding correlation degree (such as weighted calculation based on transportation route continuity, time overlap rate, vehicle matching degree, etc.), otherwise it is recorded as 0;

[0101] Perform clustering or graph search based on a pre-set correlation threshold: group the nodes in the matrix where the elements with a correlation greater than the threshold are located, and automatically identify related orders into the same aggregate set;

[0102] Generate a single settlement statement: Combine the expense details of grouped orders and record them in one settlement statement;

[0103] The combined settlement statement is provided to subsequent bill processing modules: such as bill aggregation, financial reconciliation or statistical analysis.

[0104] This combination of adjacency matrix and graph search effectively overcomes the limitations of merging based solely on business field consistency, enabling grouping of "partially similar" or "multi-dimensionally similar" billing results, further improving the efficiency and accuracy of settlement document aggregation. The resulting single, merged settlement document can be directly incorporated into subsequent bill generation or reconciliation processes, offering greater flexibility and intelligence than traditional approaches based on a complete match of business fields.

[0105] Through the above process, the system can quickly identify related orders or waybills according to pre-defined correlation models and thresholds in scenarios with large-scale, multi-dimensional billing results, reducing manual judgment or the generation of duplicate settlement orders, thereby improving reconciliation and settlement efficiency.

[0106] As an optional implementation manner, before merging the billing results based on the adjacency matrix, the method further includes:

[0107] performing individual anomaly detection on each of the billing results, and in response to the billing result satisfying an anomaly determination condition, marking it as an anomaly and excluding it from the construction of the adjacency matrix;

[0108] An adjacency matrix is constructed and a graph search is performed only for the billing results that are not marked as abnormal.

[0109] As an optional implementation manner, after merging multiple billing result groups using the adjacency matrix and generating a single settlement statement, the method further includes:

[0110] Performing group anomaly detection on each of the billing result groups, and in response to the billing result group meeting the group anomaly determination condition, marking the billing result group as abnormal pending review and performing splitting or isolation processing;

[0111] In response to determining that no group abnormality exists, a single settlement statement corresponding to the billing result group is output.

[0112] In practice, to reduce the impact of significantly abnormal billing results on the subsequent adjacency matrix construction and merging process, the system first performs "individual anomaly detection" before merging billing results based on the adjacency matrix. The main steps include:

[0113] Obtaining billing results and determining anomalies: After completing the billing calculations for the billing documents, the system obtains several billing results. For each billing result, the system checks it based on pre-configured "individual anomaly determination conditions." Individual anomaly determination conditions may include: whether the weight, volume, mileage, or other numerical fields far exceed the normal business range; whether the billing amount deviates significantly from the historical average; whether the customer is a risky customer or a high-risk carrier; and whether the input time or date fields are missing or contain obvious errors. When a billing result is determined to meet the above anomaly conditions, it is marked as "abnormal" and recorded in the anomaly list or stored separately for subsequent review.

[0114] Excluding abnormal billing results: The system retains only those not marked as abnormal for subsequent adjacency matrix construction and graph search. For those billing results marked as abnormal, a temporary settlement statement can be generated or submitted for manual review to prevent abnormal data from being mixed with normal data and causing distorted settlement statements.

[0115] Constructing and merging an adjacency matrix: After eliminating individual anomalies, the remaining normal billing results are combined into an adjacency matrix based on the similarity or correlation of the business fields. The system then performs a graph search or clustering algorithm to group billing results whose correlation meets a preset threshold into the same invoice. For details on this process, refer to the description of the adjacency matrix and graph search in the previous implementation.

[0116] Through the above approach, the system can eliminate obviously abnormal orders or billing results before constructing the adjacency matrix, reduce the probability of erroneous merging, and ensure the accuracy and credibility of subsequent settlement orders.

[0117] For further information, see Figure 3 , Figure 3 This is a flow chart of a group anomaly detection method provided in an embodiment of the present application. To further address the issue that "group anomalies" may only appear after order / billing results are merged, the system adds a "group anomaly detection" step after using the adjacency matrix to merge multiple billing result groups and generate a single settlement form. The method mainly includes steps A to D, in which:

[0118] Step A: Obtaining Merged Billing Result Groups: Based on the aforementioned adjacency matrix and graph search algorithm, the system initially aggregates several billing results that meet the correlation threshold into one or more billing result groups and generates a corresponding settlement statement for each group. While individual billing results within the group may appear normal, overall, there may be potential risks such as excessive aggregation or excessive time overlap.

[0119] Step B: Perform group anomaly determination: The system extracts statistical indicators or feature vectors for each merged billing result group, such as: total weight, total volume, and total number of orders within the group; the overlap between order quantity and time interval; whether orders are generated in a very short period of time; excessive concentration of carriers or vehicle types; and whether there are unreasonable continuous jumps in route distribution. If any indicator exceeds a preset threshold or meets the "group anomaly determination criteria," the group is marked as "abnormal pending review," triggering subsequent splitting or isolation operations.

[0120] Step C: Split or Isolate the Abnormal Group: When a billing result group is identified as a group abnormal, the system offers various handling options, such as: Entire Group Isolation: All settlement orders in the group are marked as abnormal and temporarily not output to the bill summary process. Manual review or re-splitting is prompted. Partial Split: If further analysis reveals that only some orders within the group are abnormal, these orders can be removed from the group and processed separately, allowing the remaining normal orders to continue to output settlement orders.

[0121] Step D: Outputting Normal Settlement Invoices: For billing result groups where no group anomalies are detected, the system directly outputs the corresponding single settlement invoice for inclusion in subsequent bill generation or financial reconciliation processes. By performing a secondary anomaly detection step after the merger, the system can minimize the chances of missing "group anomalies" that only manifest in the overall dimension. By adding a "group anomaly detection" step after the merger, the system can balance routine anomaly detection for individual orders with overall risk identification for order groups, effectively improving its ability to identify potential anomalies after the merger, thereby ensuring the reliability and accuracy of generated settlement invoices and bills.

[0122] By combining individual anomaly detection before adjacency matrix merging with group anomaly detection after merging, the system can promptly identify potential issues at different granularity levels (single billing result and overall order group), reducing the risk of missed or misjudgment. After determining a group anomaly, the system can choose to split or isolate it based on business needs, flexibly isolating the abnormal order group and preventing erroneous information from spreading to subsequent billing or reconciliation processes. This multi-stage detection solution is suitable for large-scale, multi-scenario logistics billing systems, ensuring the efficiency of automated merging while improving the prevention and control of order anomalies and financial risks.

[0123] For example, Figure 2 As shown, Figure 2 A billing system diagram is provided for an embodiment of the present application. There are five billing results currently pending, numbered O1, O2, O3, O4, and O5. The system needs to aggregate these billing results and generate a settlement statement for subsequent bill consolidation or reconciliation operations.

[0124] "Risk Carrier Z" in O2 means that the order is extremely risky;

[0125] O3, O4, and O5 appear normal when viewed separately, but if they are concentrated on adjacent routes for shipment within a short period of time, they may cause “group anomalies” (such as “excessive overlap in delivery times” or “excessive concentration”) after being merged.

[0126] The first stage is individual anomaly detection. The company configures several "individual anomaly" judgment rules, such as: if the carrier is on the risk list, it is considered a high-risk anomaly; if the weight or cost is higher than a certain limit, it is also considered an anomaly; if a field is obviously missing or the timestamp is unreasonable, it is also considered an anomaly.

[0127] After reading the data of O1, O2, O3, O4, and O5, the system judges according to the above rules: the carrier in O2 = "Risk Carrier Z", which triggers Rule 1, so O2 is marked as an "abnormal order"; the remaining O1, O3, O4, and O5 have no obvious violations or extreme value violations at the single data level, and are temporarily judged as "normal".

[0128] The system removes O2 from the subsequent automatic merging process or places it in the "Exception Pending Review" list for further manual review. Only O1, O3, O4, and O5 are retained for the next steps of "Adjacency Matrix Construction" and "Graph Search."

[0129] The second stage involves merging the adjacency matrix. Using O1, O3, O4, and O5 as nodes, the association is calculated based on fields such as "shipping location - receiving location," "shipping time period," "vehicle type," and "carrier." For example, if O1 and O3 both have a shipping location of City A and a receiving location of City B, similar shipping times, the same vehicle type, and the same carrier, their association is high and may reach a certain threshold.

[0130] For example, O4 and O5 have the same shipping location (City B), the same receiving location (City D), similar shipping time periods, and the same vehicle model and carrier, so the correlation is relatively high.

[0131] For example, O1 / O3 and O4 / O5: the place of shipment and the place of receipt are not exactly the same, there is a slight difference in time, and the correlation is low or 0.

[0132] Based on the non-zero correlation in the matrix, the system first merges O1 and O3 into group A; then merges O4 and O5 into another group B. A preliminary settlement form is generated for each group:

[0133] Group A: contains O1 and O3;

[0134] Group B: contains O4 and O5;

[0135] The third stage is group anomaly detection. After completing the initial merge, the system performs group dimension checks on Group A and Group B:

[0136] For Group A, the combined weight of O1 and O3 equals 800 kg, 900 kg, and 1,700 kg. The time difference is 30 minutes, and the route is City A to City B. Compared to historical statistics, 1,700 kg is not significantly excessive for small vehicles. The time overlap is significant but does not exceed the threshold (the system allows multiple orders from City A to City B within a 2-hour period). Therefore, Group A did not trigger a "group anomaly."

[0137] For Group B, after combining O4 and O5, the total weight is 850 kg + 2000 kg = 2850 kg. Both shipments were made in City B and received in City D, with the times being very close (10:00 and 10:30). According to the company's "Group Abnormality Determination Conditions," if a route exceeds 2500 kg in a single hour, it could easily lead to capacity overload or time constraints. At this point, the system detects that the threshold of 2850 kg is greater than 2500 kg and determines it as "excessive congestion." The system then marks Group B as "abnormal pending review" and does not directly output the settlement form. Instead, it triggers a notification or manual review in the system backend.

[0138] When handling group anomalies, the system can further segment them based on policy. For example, it can check whether O5's delivery time is likely to be delayed to avoid excessive overlap, or allow manual confirmation of whether the carrier can handle nearly 3 tons of cargo during the same period. If confirmed as an anomaly, the group can be split into separate order settlement forms or delayed. If business personnel confirm sufficient capacity, the group can be merged again and a normal settlement form can be output.

[0139] No group abnormality was detected in Group A (O1 + O3). The system formally generated Settlement Invoice A, accumulated the expense details (500 + 550 = 1050 yuan, etc.), and recorded the consolidation time, total quantity, etc. in the settlement invoice.

[0140] Group B (O4 + O5) is marked as a group anomaly due to excessive aggregation. Depending on the company's settings, a "manual review" or "split and then merge" process may be initiated. The official settlement document B will not be output for the time being, or a temporary settlement document with the "abnormal pending review" label will be output to prevent subsequent billing data errors.

[0141] O2 was already excluded from individual anomaly detection because the carrier was on the risk list. The system can generate a separate abnormal settlement form E2 for senior management or manual review and resolution.

[0142] In this example, through the multi-stage process of "individual anomalies first, then group anomalies": the obvious risk of O2 was promptly identified and eliminated; O4+O5 only showed the "excessive aggregation" group risk after the initial merger, and the system was able to promptly prevent the erroneous merger from entering the subsequent billing process; O1+O3 successfully completed the merger and output a normal settlement statement, ensuring that normal orders were not interfered with.

[0143] As an optional implementation method, in order to effectively utilize the adjacency matrix in ultra-large-scale orders or cross-organizational multi-business scenarios, the system combines the generation and maintenance process of the adjacency matrix with the data structure of the knowledge graph, and decomposes and partitions the adjacency matrix in the graph.

[0144] Specifically, first, a corresponding node is created in the knowledge graph for each order or billing result, and then it is preliminarily divided into different graph partitions or subgraphs based on fields such as shipping place, receiving place, carrier, business scenario, etc.

[0145] For example, orders from different legal entities, organizational dimensions, or billing periods can be stored in corresponding subgraphs or partitions. This eliminates the need to include all pairwise relationships for all orders in a single graph or adjacency matrix, significantly reducing memory and computational overhead.

[0146] Within each graph partition, the system refers to the similarity or association calculation method described previously to generate a local adjacency matrix for the orders within this partition, and records the corresponding edge relationships and attributes in the graph. If two orders meet similarity conditions in several business fields or have potential merging value, a similarity edge is added to the knowledge graph for this pair of order nodes, or the association attribute of the existing edge is updated. After the construction of the local adjacency matrix within the partition is completed, the system can complete conventional merging or bill aggregation operations locally. As long as the business entity and financial rules to which the orders belong are consistent, they can be directly merged to generate a single bill. For orders that still need to be settled and merged across partitions or legal entities, the system can dynamically assemble or connect the local adjacency matrix information of multiple partitions through federated queries or cross-subgraph retrieval at the knowledge graph level. If it is found during the inspection that orders from multiple partitions meet the merging conditions, and deeper relationships such as corresponding customer credit, tax system or collaboration agreement also meet the requirements, the system will create a corresponding merged bill node in the global knowledge graph, associate the order node or settlement node in each partition with the bill node, and mark the reason, time and audit information of this cross-partition merger in the graph.

[0147] In actual implementation, the system can use a hierarchical or super-node approach to reduce the overly detailed storage generated by massive orders. If a large number of orders in certain subgraphs are almost identical in fields such as shipping location, vehicle model, time window, etc., they can be aggregated into a super-node to represent the similarity of such orders at the top level. When more detailed item-by-item merging or anomaly determination is required, the system drills down to the specific order level contained in the super-node to retrieve the corresponding local adjacency information or partition content. Through this strategy that combines partitioning and stratification, the system can effectively manage, retrieve and infer the relevance of millions or even hundreds of millions of orders in the knowledge graph, and can also incrementally maintain the similarity edges of related subgraphs or super-nodes when updating order data, thereby taking into account high concurrency and real-time requirements.

[0148] After completing the maintenance of the partitioned or hierarchical adjacency matrix, the system will further perform cross-entity reasoning and queries based on the multi-entity relationships of the knowledge graph when aggregating or processing bills. When merging bills, in addition to referring to the similarity information of orders within the same region or the same legal person, the contract to which the order belongs, the customer's credit score, historical dispute records, and whether there are financial sharing agreements between legal persons will also be checked. If all of the above dimensions meet the merging strategy, multiple settlement order nodes or order nodes can be merged into the same billing node across partitions and subgraphs; if the carrier corresponding to a certain region or legal person is high risk, or the customer is on the exception list, this part of the settlement order can be split or isolated according to pre-set rules to avoid incorrect merging or the spread of financial risks. In this way, the system forms a comprehensive data network within the knowledge graph that covers the correlation of the adjacency matrix and semantic information such as contracts, credit, and organizations, and can execute more flexible decision logic in the bill aggregation stage.

[0149] In this process, the system can integrate existing graph databases and big data frameworks to deploy the computation and partitioned storage of local adjacency matrices as distributed tasks, leveraging multiple nodes to parallelize order similarity calculations or perform large-scale graph traversals. For federated queries or cross-partition reasoning, the graph database's multi-graph search or joint indexing can be leveraged to promptly retrieve order, settlement, and contract information across legal entities, account periods, or geographic regions.

[0150] This ensures rapid response to local orders in each partition while enabling global consolidation decisions and audit trails when unified reconciliation or financial analysis is required. By decomposing the adjacency matrix and embedding it into the knowledge graph, the system achieves data scale expansion and real-time high-concurrency access in multiple business scenarios. It also leverages graph reasoning to identify deeper business rules and exceptions, providing robust scalability and accuracy for large-scale logistics billing and multi-dimensional financial accounting.

[0151] For example, the backend first receives and parses massive data files containing order information. Key field values for each order are stored as vectors, including shipping location, delivery location, vehicle type, carrier, and billing amount. The system then calculates the similarity between orders from these vectors, for example by comparing matching scores or vector distances for identical fields. The similarity results are stored in a distributed file system, forming a block-by-block adjacency matrix representation. Each block may correspond to matching information between tens of thousands of orders, recording the identifiers of the two orders, their similarity vectors, and their feature scores.

[0152] At the knowledge graph level, a globally unique ID is assigned to each order node, and the order pairing information in the similarity block is mapped to edges in the graph. When importing these edges, the system will store order nodes belonging to the same legal entity or grouped by similar fields on the same database shard based on the business logic partitioning rules. The import process will traverse the block file, read line by line (order A, order B, similarity value) and create or update an edge entity, setting its attributes such as similarity = a certain value or time_overlap = a certain time difference. To avoid overloading a single shard, the system combines pre-configured sharding strategies to disperse order nodes by organization, geographic region, or billing period range, and mark the partition information to which the nodes and edges belong in the graph metadata.

[0153] For example, when importing order nodes and their matching relationships into the knowledge graph, each edge entity, in addition to recording the identifiers of Order A and Order B, also has two key attributes: similarity and time overlap. Similarity represents the cosine similarity between the feature vectors V_A and V_B corresponding to Order A and Order B. Similarity ranges from 0 to 1, with larger values indicating a higher degree of match between the two orders in key fields such as shipping location, destination, vehicle type, carrier, and billing amount.

[0154] Time_overlap indicates the temporal proximity of two orders. It is calculated by calculating the difference between their timestamps (in Unix timestamps, minutes, or hours). A smaller time_overlap value indicates a closer temporal proximity between the two orders.

[0155] In the subsequent sharding strategy and replenishment task generation, the system can set thresholds based on the above attribute values, and batch merge or prioritize orders that are highly similar and close in time to avoid overloading a single shard and improve scheduling efficiency.

[0156] At runtime, if the system detects that a shard contains a large number of orders that are highly similar and have almost identical fields, it will create a "supernode" within the shard to store the common attributes of this batch of orders in the form of vectors, and treat the remaining personalized fields as a list of sub-vectors for subsequent retrieval when performing more refined merging or splitting of parts of the orders. This can reduce the number of nodes that actually need to be maintained within the shard, and also reduce the scale of traversal when searching or updating the graph. The supernode is still presented as a normal node at the graph database level, but it will have a structured field that references the list of sub-orders and is incrementally updated based on changes in similarity.

[0157] During bill aggregation, if orders need to be merged across multiple partitions or shards, the system first retrieves the cross-shard locations of these orders in the central scheduling module and then queries the corresponding graph database instances to obtain similarity edges and other business information about the orders. The engine reads the order vector data and similarity fields from different shards and re-merges or recalculates them to confirm whether they can be attributed to the same billing node. If the order nodes involved all have contracts with similar or identical business entities, and additional conditions such as credit ratings and tax rules are matched in the knowledge graph to meet the merging criteria, the system generates or updates a billing node, associates it with the relevant order nodes, and marks the new aggregation status at the "supernode" layer or vector block layer. If the data from any shard returns an exception or the legal entity to which the order belongs is found to be incompatible with other orders, the system will split or isolate the order based on the exception handling strategy and will not perform the cross-shard bill merge.

[0158] After the order or similarity data is updated, the system can trigger an incremental calculation to correct the attributes of the block adjacency matrix and the knowledge graph edge. For example, when the carrier field of an order is changed, or the similarity of a new order with an existing order exceeds the threshold, the corresponding entry will be added to the original adjacency matrix block, and an edge will be added or updated between the order nodes in the corresponding shard of the graph database. Fields such as similarity or time overlap will be rewritten synchronously to ensure that the knowledge graph remains consistent with the underlying adjacency block. Ultimately, this approach of decomposing and managing the adjacency matrix in the graph allows the system to maintain good computing efficiency and storage scalability even with massive order data, and by associating similarity vectors with business fields in the same graph, it provides a consistent data foundation and a dynamically scalable processing model for subsequent multi-dimensional bill consolidation, anomaly detection, or reconciliation.

[0159] Based on the same inventive concept, a logistics billing engine system corresponding to the logistics billing engine method is also provided in the embodiment of the present application. Since the principle of solving the problem by the system in the embodiment of the present application is similar to the above-mentioned logistics billing engine method in the embodiment of the present application, the implementation of the system can refer to the implementation of the method, and the repeated parts will not be repeated.

[0160] Reference Figure 4 FIG. 1 is a schematic diagram of a logistics billing engine system provided in an embodiment of the present application, and the system includes:

[0161] The acquisition module 10 obtains the billing document and extracts the business field and the metering field from the billing document;

[0162] The first calculation module 20 matches the pre-configured charging rules according to the service field and the metering field to generate a corresponding fee calculation plan;

[0163] A second calculation module 30 performs calculations on the meter field based on the fee calculation scheme to obtain a billing result;

[0164] Settlement module 40 collects the billing results and related document information, constructs multiple billing result groups based on the association of business fields, and generates corresponding settlement documents based on each billing result group;

[0165] The generation module 50 aggregates multiple settlement documents and forms an invoice according to a pre-set merging rule.

[0166] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

Claims

1. Logistics billing engine method, characterized in that: include: Obtaining a billing document, and extracting a business field and a metering field from the billing document; According to the business field and the metering field, matching the pre-configured billing rules, generating a corresponding fee calculation plan; Based on the fee calculation scheme, the meter field is operated to obtain a billing result; The billing results and related document information are aggregated, multiple billing result groups are constructed based on the association of business fields, and corresponding settlement documents are generated according to each billing result group; Aggregate multiple settlement documents and form a bill according to pre-set consolidation rules; The forming of the settlement statement further includes: assigning a unique identifier to each billing result, and constructing an adjacency matrix based on matching conditions in the service fields between the billing results; performing a graph search for non-zero associations in the adjacency matrix, and merging multiple billing results whose associations meet a preset threshold to generate a single settlement statement; Before the merging and generating of a single settlement statement, the method further includes: performing individual anomaly detection on each of the billing results; in response to the billing result meeting an anomaly determination condition, marking it as an anomaly and excluding it from the construction of the adjacency matrix; constructing an adjacency matrix and performing a graph search only for the billing results that are not marked as abnormal; After merging the plurality of billing result groups using the adjacency matrix and generating a single settlement statement, the method further includes: Performing group anomaly detection on each of the billing result groups, and in response to the billing result group meeting the group anomaly determination condition, marking the billing result group as abnormal pending review and performing splitting or isolation processing; In response to determining that no group anomaly exists, outputting a single settlement statement corresponding to the billing result group; The group anomaly detection includes: obtaining a merged billing result group, extracting statistical indicators or feature vectors of the billing result group, the statistical indicators or feature vectors including the total weight, total volume, total number of orders in the group, the overlap between the order quantity and the time interval, the concentrated generation time of orders, the concentration of carriers or vehicle types, and the degree of continuous jumps in route distribution; In response to the statistical indicator or characteristic vector exceeding a preset threshold, the billing result group is determined to be a group abnormality and marked as abnormal pending review; Split or isolate the abnormal billing result group awaiting review, including isolating the entire group of billing results, or partially splitting the abnormal billing results within the group; For the billing result group in which no group abnormality is detected, the corresponding single settlement statement is output.

2. The logistics billing engine method according to claim 1, characterized in that: The matching of pre-configured charging rules includes: Performing conditional judgment on the service field to determine a rate field interval corresponding to the service field; According to the rate field interval, the meter field is segmented and a segmented rate is obtained; The fee calculation scheme is generated based on the segmented rates.

3. The logistics billing engine method according to claim 1, characterized in that: When generating the fee calculation plan, the following is also included: Set a minimum billing amount and a maximum billing amount. If the calculated billing result is less than the minimum billing amount, the minimum billing amount will be used; if it is greater than the maximum billing amount, the maximum billing amount will be used; Set the minimum billing quantity and the maximum billing quantity. When the calculated quantity is less than the minimum billing quantity, the minimum billing quantity is used. When the calculated quantity is greater than the maximum billing quantity, the maximum billing quantity is used.

4. The logistics billing engine method according to claim 1, characterized in that: The step of aggregating the billing results and related document information, constructing multiple billing result groups based on the association of business fields, and generating corresponding settlement documents according to each billing result group includes: Filtering the billing results according to pre-set filtering conditions, wherein the filtering conditions include at least one of a carrier, a shipper, and a transportation type; In response to the fact that the order date, transportation route, consignee and delivery location information are the same, multiple billing results that meet the filtering conditions are merged to generate a single settlement statement.

5. The logistics billing engine method according to claim 4, characterized in that: Aggregating multiple settlement documents and forming an invoice according to pre-set merging rules includes: Filtering the settlement documents according to pre-set bill generation filtering conditions, wherein the bill generation filtering conditions include at least one of customer identification, billing cycle, or organization dimension; In response to satisfying the bill generation filtering condition, aggregating and merging the plurality of single settlement bills; Combine consolidated statement information into a single bill.

6. The logistics billing engine method according to claim 5, characterized in that: The aggregating multiple settlement documents and forming an invoice according to a pre-set merging rule further includes: Create graph nodes in the knowledge graph database to represent business entities such as settlement orders, orders, carriers, transportation routes, and billing cycles, as well as edges to represent dependencies or associations between business entities. Writing the key field information of the settlement form into the knowledge graph database to form a graph data structure for bill merging; Performing reasoning operations on the settlement order nodes and their associated relationships in the knowledge graph database based on pre-configured business rules or an inference engine to automatically identify a set of settlement order nodes that meet bill consolidation conditions; The set of settlement order nodes identified by the reasoning operation is linked to the adjacency matrix or the anomaly detection module for processing. When it is determined that no anomaly exists, the merged bill is output. If it is determined that an anomaly exists, the relevant settlement orders are split or isolated to dynamically aggregate the bills.

7. The logistics billing engine method according to claim 6, characterized in that: The aggregating multiple settlement documents and forming an invoice according to a pre-set merging rule further includes: Reading the vectorized field information generated for each order from a storage medium, and performing batch similarity calculation on the vectorized field information to form an adjacency matrix for the partial blocks, wherein the adjacency matrix records non-zero similarities between order pairs; When importing the adjacency matrix into the knowledge graph database, a corresponding graph node is created or updated for each order, and a relationship edge is established or updated between the graph nodes based on the similarity result in the adjacency matrix, and the relationship edge carries a similarity vector or a correlation attribute; Generate a supernode for a set of orders with a similarity greater than a preset similarity threshold and the same field value, treat the supernode as a single node object in the knowledge graph database, and attach the differentiated fields of each order in the order set to it in the form of an additional vector; When performing bill aggregation, whether each order meets the merging conditions is determined based on the super node and its additional vector, and reasoning is performed in combination with cross-entity information. In response to meeting the bill merging conditions, a corresponding bill node is created in the knowledge graph database and associated with the relevant order node.

8. A logistics billing engine system, configured to implement the logistics billing engine method according to any one of claims 1 to 7, characterized in that: include: The acquisition module obtains the billing document and extracts the business field and the metering field from the billing document; A first calculation module, matching pre-configured billing rules according to the service field and the metering field, and generating a corresponding fee calculation plan; A second calculation module, based on the fee calculation scheme, performs calculations on the meter field to obtain a billing result; The settlement module collects the billing results and related document information, constructs multiple billing result groups based on the association of business fields, and generates corresponding settlement documents based on each billing result group; The generation module aggregates multiple settlement documents and forms an invoice based on pre-set merging rules.

Images