Customer billing method based on hierarchical contract configuration and quote analysis

Abstract

The application discloses a customer account statement generation method based on hierarchical contract configuration and quotation analysis. The method obtains a customer contract configuration request and quotation source data, performs multi-channel analysis on the contract main text, attachments, quotation forms, email texts, picture screenshots, scanned copies and manually entered fields, generates candidate quotation fields carrying source page numbers, layout coordinates, segment hashes, analysis channels and confidence levels, forms structured charging items based on field dictionaries, synonym mappings, fee types, charging modes, currency dictionaries and verification rules, constructs a hierarchical contract configuration tree, binds contract evidence, analysis evidence, manual confirmation records and version snapshots, determines target charging rules when taking values, batch charging, pre-verification or historical re-calculation, generates account statement details and traceability hashes, and improves the accuracy, stability, reproducibility and auditing efficiency of the account statement generation.

Description

Technical Field

[0001] This invention relates to the fields of enterprise management software, contract data governance, quotation parsing, business rule engine, automatic settlement, bill generation, historical snapshots and traceable auditing, and in particular to a method for generating customer reconciliation statements based on hierarchical contract configuration and quotation parsing. Background Technology

[0002] In business scenarios such as global hiring, HR outsourcing, payroll, EOR, settlement, and customer reconciliation, customer contracts are typically not a single structured data table. Instead, they consist of a main contract, a framework agreement, supplementary contracts for different countries or regions, quotation attachments, service fee tables, email confirmation records, screenshots, scanned copies, and subsequent supplementary agreements. These documents may be generated by different departments, teams in different countries, or different systems, and there may be differences in field naming, currency, validity period, tax calculation methods, payment cycles, and discount agreements.

[0003] Existing customer contract configuration methods largely rely on manual contract reading and manual entry of billing fields. This method is feasible for a small number of customers, a single country, or a fixed-fee model, but when multiple customers, multiple countries, multiple business lines, and multiple billing periods are billed in parallel, problems easily arise such as missing quotation fields, inconsistent fee type mappings, overwriting of historical versions, unclear boundaries between framework agreements and national contracts, difficulty in tracing contract evidence, and inability to reproduce the original calculation process in case of customer disputes.

[0004] Existing rule engines typically focus on rule execution itself, but lack sufficient support for the continuous technical chain between quote source parsing, contract level configuration, fee item version snapshots, evidence binding, manual confirmation records, and billing traceability. For example, a client's framework agreement stipulates a minimum fee and payment cycle, while a national contract stipulates that service fees are calculated as a percentage of the employer's costs. If the system cannot identify which fields can be inherited and which fields must be covered by the national contract, the automatic billing results may be inconsistent with the contract stipulations.

[0005] Furthermore, quote sources are often not all structured tables. Sales personnel may confirm discounts via email, provide tiered pricing via contract attachments, show signed versions via scanned copies, or send provisional quotes via screenshots. If the system cannot convert these sources into a unified candidate quote field and retain the source page number, layout coordinates, fragment hash, and parsing channel identifier, then subsequent manual confirmation, rule pre-validation, cost calculation, and customer dispute resolution will lack a reliable evidentiary basis.

[0006] Therefore, a technical solution is needed that can extract charging fields from multimodal pricing sources, construct customer contract hierarchical configurations, maintain indelible version snapshots, bind contract evidence, automatically select charging rules, and output traceable customer statement details to improve the accuracy, automation, auditability, and historical reproducibility of customer statement generation. Summary of the Invention

[0007] The purpose of this invention is to provide a method for generating customer account statements based on hierarchical contract configuration and quotation parsing, so as to solve the problems in the background art.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a method for automatically generating customer account statements based on hierarchical contract configuration and multimodal quotation parsing, characterized in that: S1, acquiring customer contract configuration requests and quotation source data, wherein the quotation source data includes at least one of contract text, contract attachments, quotation form tables, email quotation text, image quotation screenshots, scanned quotation documents, and manually entered fields; S2, performing multimodal quotation parsing on the quotation source data, outputting a candidate quotation field set containing original field names, original field values, standard field names, standard field values, source file identifiers, source page numbers or page coordinates, source fragment hashes, parsing channel identifiers, parsing time, and parsing confidence; S3, based on a field dictionary, a synonym mapping table, a fee type enumeration, a charging mode enumeration, a currency dictionary, a country or region dictionary, and verification rules, standardizing, conflict checking, and manually confirming and writing back the candidate quotation field set to generate a structured account statement. S4. Based on the customer identifier, country or region identifier, tenant or system namespace, contract scope, contract status, and field inheritance strategy, construct a customer contract configuration tree containing framework protocol configuration nodes and country contract configuration nodes; S5. Establish contract evidence relationships, parsing evidence relationships, manual confirmation records, and fee item version snapshots for the fee items in the structured fee item set; S6. Receive value requests from the business system, and determine the target fee rule version in the customer contract configuration tree based on the customer identifier, country or region identifier, business type, employee nature, fee type, billing period, and billing input vector in the value request; S7. Based on the target fee rule version, call the corresponding billing kernel function to generate customer statement details; S8. Associate and output the target fee rule version, contract evidence relationships, parsing evidence relationships, manual confirmation records, calculation process snapshots, and customer statement details, and generate a traceability hash for review.

[0009] The multimodal quotation parsing includes: performing paragraph segmentation, clause number recognition, key phrase recognition, amount expression recognition, effective range recognition, and context window extraction on text documents; performing header recognition, merged cell expansion, row and column semantic normalization, currency column recognition, fee cycle recognition, and remarks column parsing on table files; performing OCR recognition, row block reconstruction, column block reconstruction, page coordinate binding, and low confidence interception on image quotation screenshots or scanned copies; performing joint parsing of subject, sender, recipient, sending time, quotation fragments in the body, and attachment list on email quotation text; and performing field format validation and source supplementation validation on manually entered fields.

[0010] Standardizing the candidate quotation field set includes: retaining the original field name and original field value for each candidate field; mapping service fee, management fee, monthly service fee, and service charge to a unified fee type; mapping fixed, flat amount, and fixed amount to a fixed amount pattern; mapping percentage, rate, and proportional to a proportional pattern; mapping tier, ladder, and ladder fees to a ladder pattern; and performing format validation on the amount field, percentage field, date field, currency field, billing cycle field, and tax field respectively.

[0011] When the resolution confidence level is lower than a preset threshold, there are multiple candidate amounts in the same quotation source, the currency is missing, the effective period of the fee items overlaps, the fee model and parameters do not match, the contract evidence is missing, the manual confirmation record is expired, or the applicability relationship between the framework agreement configuration and the national contract configuration cannot be determined, a pending confirmation task is generated. The pending confirmation task displays the original source fragment, candidate resolution results, suggested standard fields, conflict reasons, impact on payment period and optional processing actions, and generates a new fee item version snapshot after confirmation.

[0012] The customer contract configuration tree uses a unique contract configuration key. Generate, where C represents the customer identifier, N represents the country or region identifier, and S represents the tenant or system namespace; and pass a unique constraint function. Only one valid contract configuration node exists for the same tenant, the same customer, the same country or region within the same valid time interval, where T represents the valid time interval.

[0013] The customer contract configuration tree supports field inheritance strategies, including prohibiting inheritance, allowing inheritance, displaying inheritance only, and requiring review for inheritance. When the national contract configuration node does not configure a target field and the target field allows inheritance, the field value is read from the framework protocol configuration node. When the target field is marked as a national exclusive field, inheritance from the framework protocol configuration node is prohibited. When the target field is marked as requiring review for inheritance, the inherited value enters the pending confirmation task and does not participate in automatic billing before confirmation.

[0014] The structured fee items include customer identifier, country or region identifier, business line, employee nature, fee type, fee item name, fee model, fee amount, fee ratio, tier boundary, tier billing base, minimum fee, maximum fee, currency, tax caliber, effective start time, effective end time, contract evidence identifier, parsed evidence identifier, manual confirmation identifier, and version status.

[0015] The contract evidence relationship includes contract document identifier, contract name, contract status, signing entity, clause location, attachment page number, source fragment hash, upload time, evidence validity status, and evidence fingerprint; when the contract document expires, is replaced, becomes invalid, or is archived, the evidence fingerprint in the historical paid item version snapshot is retained, and a new record of evidence status change is added.

[0016] Creating version snapshots for paid items includes: when adding a new paid item version, updating the effective end time of the previous paid item version to a preset time boundary before the effective start time of the new paid item version, forming non-overlapping version time intervals; prohibiting overwriting modifications to already effective versions, and allowing editing of draft versions that have not yet taken effect, but generating a commit snapshot and event hash when committing to take effect.

[0017] Determining the target charging rule version includes scoring based on priority. Sort the candidate charging rule versions; among them This indicates the hit score for the contract configuration level. This indicates the score that matches the valid range of the billing period and version. The score indicates the validity of the evidence. This indicates the matching score based on the business dimension. This indicates the quality score of the quote parsing or the quality score of the manual confirmation. When there are multiple candidate versions with the highest score, the target charging rule version is determined in the following order: national contract configuration takes precedence over framework agreement configuration, manual confirmation takes precedence over automatic parsing, and the most recently effective version takes precedence over the earlier version.

[0018] The billing kernel function includes a fixed amount kernel function, a proportional kernel function, a fixed amount tiered kernel function, a proportional tiered kernel function, a minimum charge kernel function, a maximum charge kernel function, and a tax surcharge kernel function; when the charging mode is a proportional tiered mode, the billing kernel function satisfies Where z represents the step index, and This represents the q-th step boundary. This represents the q-th step ratio. This represents the billing base for the q-th tier.

[0019] Generating customer statement details involves mapping at least one input item from EOR, Payroll, and Settlement transactions—including employee, payment period, salary, annual salary, employer costs, service fees, one-time fees, reimbursement service fees, security deposit, VAT, and WHT—to a billing input vector. For each expense item, the calculation of the charge amount is performed line by line, and the output includes the charge item name, charge type, charge rule text, charge amount, currency, contract configuration code, charge item version number, evidence identifier, calculation formula, calculation result, exception status, and source hash.

[0020] The value retrieval requests include real-time value retrieval requests, batch bill generation requests, rule pre-validation requests, and historical billing period recalculation requests. For historical billing period recalculation requests, the corresponding historical version snapshot is read according to the billing period, and the use of the latest current configuration to replace the historical snapshot is prohibited. For rule pre-validation requests, evidence missing verification, version range verification, currency consistency verification, fee mode parameter integrity verification, inheritance strategy verification, and rule conflict verification are performed before the customer generates the bill.

[0021] Compared with existing technologies, this invention has at least the following beneficial effects: First, by parsing multimodal quotations and standardizing fields, the charging terms in contract texts, quotation attachments, tables, email texts, screenshots, and scanned documents are converted into unified structured charging items, reducing the cost of manual data entry and manual pricing; Second, by using customer contract configuration trees and field inheritance strategies, the value boundaries between framework agreements and national contracts are clarified, reducing cross-country billing errors; Third, by using non-overwhelmable version snapshots and evidence relationship retention, the original rules can be reproduced during historical billing period recalculation; Fourth, by using billing kernel functions and rule priority scoring, the stability of automatically selecting target charging rules is improved; Fifth, by using billing traceability hashes and audit event chains, the efficiency of customer dispute resolution and the credibility of internal audits are improved. Detailed Implementation

[0022] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should be understood that the described embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the invention. Where there is no conflict, the technical features in the following embodiments can be combined with each other.

[0023] like Figure 1 As shown, in this embodiment, the customer contract configuration module receives a contract configuration request. The contract configuration request can be initiated by the contract management system, sales quotation system, business operations system, or manual configuration page, and includes customer identifier, tenant identifier, country or region identifier, business line, contract document list, quotation source list, and target effective time.

[0024] The system first performs access processing on the quotation source data. For file-based sources, the system records the file identifier, file name, file type, upload time, uploader, file hash, and file version. For email-based sources, the system records the email subject, sender, recipient, sending time, body hash, and attachment relationship. For manually entered sources, the system records the person who entered the data, the entry time, the entry point, and a description of the manual entry. Using this metadata, subsequent parsing results can trace back to the original source.

[0025] The system then selects the appropriate parsing channel based on the source type. Text contracts go through the terms parsing channel, quotation forms go through the forms parsing channel, screenshots and scans go through the OCR parsing channel, emails go through the email parsing channel, and manually entered fields go through the format validation channel. Each parsing channel outputs a candidate quotation field object with a uniform format, preventing the subsequent rules engine from directly dealing with different file formats.

[0026] Candidate quote field objects are entered into the field standardization module. The field standardization module normalizes fields with different names, languages, or expressions into structured fields based on field dictionaries, synonym mappings, currency dictionaries, country or region dictionaries, fee type enumerations, and charging model enumerations. For example, service charge, monthly service fee, management fee, and service fee can be standardized as a service fee type; percentage, rate, and proportional charging models can be standardized as proportional charging models.

[0027] Standardized fields are not immediately included in automatic billing. The system performs conflict checks, integrity checks, and evidence checks on them. If a field has insufficient confidence, is missing currency, the amount expression does not match the billing model, there are multiple valid amounts for the same billing period, or contract evidence is missing, the system generates a pending confirmation task. Only fields that pass automatic verification or manual confirmation are allowed to form effective structured billing items.

[0028] After a structured fee item enters the hierarchical configuration module, the system locates the contract configuration tree based on the customer identifier, country or region identifier, and tenant namespace. If the request involves a specific country, the country contract configuration node is written first; if the request involves multiple countries sharing the same agreement, the framework protocol configuration node is written, and an inheritance strategy is used to control whether it can be inherited by the country node.

[0029] When a business system initiates a customer's billing statement retrieval request, the system does not directly read the current field value. Instead, it identifies candidate billing rule versions based on the billing period, business type, employee nature, and expense type, and sorts them based on evidence validity, version validity range, business dimension matching, and parsing quality. After matching the target billing rule version, the billing calculation module calls the corresponding billing kernel function to generate the billing details.

[0030] Each customer statement detail is linked to the target billing rule version, contractual evidence, parsed evidence, manual confirmation records, and a snapshot of the calculation process. The system inputs these objects into a hash function to generate a traceHash or billHash, which is used to determine whether subsequent data has been modified and to quickly locate the source of charges in case of customer disputes.

[0031] like Figure 3 As shown, multimodal quote parsing is not a simple OCR or text extraction, but a multi-channel parsing process configured for paid items. The system selects a parser based on the quote source type and writes the parsing results into a candidate quote field set. The candidate quote field set includes at least the field name, field value, field type, fee type, payment mode, currency, payment period, source location, parsing channel, and confidence level.

[0032] For the main body of the contract, the system first performs paragraph segmentation and clause number recognition to divide the contract text into locatable clause fragments; then it identifies the amount expression, percentage expression, effective date, termination date, payment cycle, tax scope, and fee name; finally, it determines the fee type corresponding to the amount or percentage based on the context window. The context window may include the target sentence, the previous clause, the next clause, and the current heading level.

[0033] For tabular files, the system first identifies the table header and multi-level headers. If merged cells exist, the merge relationship is expanded, and the parent and child headers are combined into candidate field names. The system further identifies the currency column, billing cycle column, country column, business type column, employee type column, and remarks column to avoid misinterpreting historical descriptions in the remarks as valid billing amounts.

[0034] For image-based price quote screenshots or scanned documents, the system performs OCR recognition, row block reconstruction, column block reconstruction, and layout coordinate binding. The system binds each candidate amount or percentage to a page number, coordinate range, and source fragment hash. If the OCR confidence level is below the threshold or the layout structure cannot be determined, the result enters the manual confirmation queue to prevent low-quality recognition results from automatically being included in the billing rules.

[0035] For email quotation text, the system parses the email subject, body, sender, recipient, sending time, and attachment list. If the email body contains directional statements such as "subject to attachment" or "execute according to the latest quotation," the system establishes a reference relationship between the email body parsing results and the attachment parsing results, and prioritizes the explicitly referenced attachment quotation when selecting rules.

[0036] For manually entered fields, the system does not simply accept the input, but requires the entered field to be linked to a source description or supplementary evidence. When a manually entered field conflicts with an automatically parsed field, the system retains both and determines whether the automatically parsed result can be overridden based on the manual confirmation record, the confirmer's permissions, and the confirmation time.

[0037] Through the above processing, the system can convert quotation content from multiple sources into a unified set of candidate quotation fields, while retaining the source trajectory and quality information of each field, providing a technical foundation for subsequent field standardization, version snapshots, and customer dispute handling.

[0038] The field standardization module maintains a field dictionary, a synonym mapping table, a fee type enumeration, a charging mode enumeration, a currency dictionary, a country or region dictionary, and a set of validation rules. The field dictionary defines standard field names, field types, whether they are required, allowed inheritance strategies, allowed business lines, and acceptable value ranges.

[0039] When a candidate quote field enters the standardization module, the system first matches the field name, and then matches the field value expression. For example, "2% of employer cost" is identified as a percentage mode, with the employer cost as the billing base; "USD 500 per employee per month" is identified as a fixed amount mode, with a monthly billing cycle and the employee as the billing object; and "minimum fee 1000" is identified as a minimum fee constraint.

[0040] The system also validates the relationships between fields. If the charging model is a fixed amount, the amount and currency must be present; if the charging model is a percentage, the percentage and the billing base must be present; if the charging model is tiered, the tier boundaries, tier percentages, or tier amounts must be present; if the charging item includes taxes and surcharges, the tax scope or the national default tax rule must be specified.

[0041] Conflict checks include same-source conflicts, cross-source conflicts, and version conflicts. Same-source conflicts refer to multiple candidate amounts appearing in the same file or email, all pointing to the same fee type in the context; cross-source conflicts refer to different amounts or different effective dates between the contract body, quotation attachments, and email confirmations; version conflicts refer to overlapping time periods between the new fee item version and the already effective version.

[0042] For conflicts that can be handled automatically, the system processes them according to preset priorities. For example, signed contracts take precedence over draft contracts, national contracts over framework agreements, manually confirmed results over automatically parsed results, and the most recently effective supplementary agreements over earlier quotation emails. For conflicts that cannot be handled automatically, the system generates a task to be confirmed and retains all candidate sources.

[0043] The tasks to be confirmed include conflicting fields, candidate values, source files, source page numbers or coordinates, parsing channels, confidence levels, suggested actions, and impact on billing periods. After reviewer confirmation, the system generates a confirmation record and binds it to the corresponding billing item version snapshot.

[0044] like Figure 2 As shown, the customer contract configuration tree includes at least a customer root node, a framework protocol configuration node, and a country contract configuration node. The customer root node represents the customer's unique identity within the tenant or system namespace; the framework protocol configuration node represents common contractual agreements across countries or business lines; and the country contract configuration node represents contractual agreements for specific countries or regions.

[0045] The system configures a unique key through the contract. The configuration node identifies the country contract, where C represents the customer identifier, N represents the country or region identifier, and S represents the tenant or system namespace. For framework protocol configuration nodes, N can be set to a global identifier or a regional identifier. The system uses a unique constraint function to prevent multiple valid configuration nodes from existing within the same customer, country or region, or time interval.

[0046] Each configuration node includes node status, applicable business line, applicable employee type, default currency, default tax calculation method, default payment cycle, evidence relationship set, and set of chargeable item versions. Node status can include draft, pending review, effective, invalid, and archived. Only effective nodes can be triggered by the automatic billing process.

[0047] The field inheritance strategy is used to resolve the value boundaries between the framework protocol and national contracts. If a field is allowed to be inherited, it can be read from the framework protocol node if the national node is not configured; if a field is prohibited from inheritance, the national node must enter a pending confirmation task if the field is missing; if a field is only allowed to be displayed, it can be displayed on the interface but will not participate in automatic billing; if a field requires verification of inheritance, it must be manually confirmed before it can participate in billing.

[0048] Through the customer contract configuration tree, the system can form a stable value path in multi-country contract scenarios. For example, customer A's framework agreement stipulates a monthly payment cycle, the country SG contract stipulates a service fee of 8% of the employer's costs, and the country MY contract stipulates a fixed service fee of $300. When billing from SG, the system reads the country SG service fee and inherits the framework agreement payment cycle; when billing from MY, it reads the country MY fixed amount and similarly inherits the payment cycle.

[0049] like Figure 4 As shown, a paid item version snapshot is used to record the complete status of a paid item within a specific valid period. The snapshot includes the paid item field, version number, effective start time, effective end time, version status, contract evidence relationship, parsed evidence relationship, manual confirmation record, creation event hash, and previous version hash.

[0050] The contractual evidence relationship is used to link paid items with contract documents. Its fields include contract document identifier, contract name, signing entity, contract status, clause location, attachment page number, source fragment hash, upload time, evidence validity status, and evidence fingerprint. The parsing evidence relationship is used to link paid items with parsing results. Its fields include parsing task identifier, parsing channel, original field name, original field value, standard field name, standard field value, source coordinates, and parsing confidence level.

[0051] When a new paid item version is added, the system generates a snapshot of the new version and updates the effective and end times of the previous version to a preset time boundary before the effective start time of the new version. Modifications to already effective versions cannot be overwritten; if corrections to already effective content are needed, the system must create a new corrected version and retain the original version for recalculation of historical billing periods.

[0052] When contract documents expire, are replaced, become invalid, or are archived, the system does not delete historical evidence relationships, but instead adds new records of evidence status changes. The evidenceId referenced by historical invoices can still read the evidence fingerprint and source fragment hash at that time, thus ensuring that the chain of evidence remains unbroken during the review of historical invoices.

[0053] In one implementation, the system generates an event hash for each version commit. Subsequent events reference the hash of the previous event to form an event chain. If any historical event is tampered with, the event chain verification fails.

[0054] like Figure 5 As shown, after the business system initiates a value retrieval request, the rule selection module first locates the contract configuration tree based on the customer identifier, country or region identifier, and tenant namespace, and then filters candidate charging rule versions based on business type, employee nature, fee type, and billing period.

[0055] For each candidate charging rule version, the system calculates a priority score. .in This indicates the hit score for contract configuration levels, with national contract configurations having a higher hit score than framework agreement configurations. This indicates the score that matches the valid range of the billing period and the version. Indicates the score for the validity of evidence; This indicates the matching score based on the business dimension; This indicates the quality score of the quote analysis or the quality score confirmed manually.

[0056] If the highest score corresponds to only one candidate version, that candidate version is determined as the target billing rule version. If the highest score corresponds to multiple candidate versions, the system processes them according to a preset decision order: national contract configuration takes precedence over framework agreement configuration, manual confirmation takes precedence over automatic parsing, signed contracts take precedence over email quotations, and the most recently effective version takes precedence over earlier versions. If a determination still cannot be made, a rule conflict exception is generated and automatic billing is prevented.

[0057] For pre-verification requests, the system may only return the hit result, conflict information, and suggested handling actions, without actually generating billing details. For real-time value retrieval requests, the system returns the target billing rule version and the single billing result. For batch billing requests, the system processes them in groups by customer, country or region, business type, and billing period; failure in one group does not affect the continued execution of other groups.

[0058] The billing calculation module calls the corresponding billing kernel function according to the billing mode in the target billing rule version. The fixed amount kernel function directly returns the agreed amount; the proportional kernel function returns the amount by multiplying the billing base by the agreed proportion; the minimum charge kernel function imposes a lower limit on the calculation result; the maximum charge kernel function imposes an upper limit on the calculation result; and the tax surcharge kernel function calculates the surcharge amount according to the tax scope and national or regional tax rules.

[0059] For the proportional step mode, the system uses Calculate, where z represents the step index, and This represents the q-th step boundary. This represents the q-th step ratio. This represents the billing base for the q-th tier, and I represents the indicator function. The tier boundaries, percentages, and billing bases are all from a snapshot of the target charging rules version.

[0060] For fixed-amount tiered billing, the system locates the tiered intervals according to the tiered indicators and reads the corresponding fixed amounts. If there are gaps or overlaps in the tiered intervals, the system generates incomplete parameters or parameter conflicts. If the billing period spans two valid versions, the system calculates the fees separately according to the period splitting strategy and outputs two fee lines or a fee line with a period splitting identifier in the billing details.

[0061] Each billing calculation generates a snapshot of the calculation process. This snapshot includes the input vector, the version of the matched rule, the name of the billing kernel function, the calculation formula, parameter values, intermediate results, the final amount, currency, rounding rules, and any exceptions. This snapshot is saved in conjunction with the customer's statement details for subsequent review.

[0062] The statement generation module maps business system inputs to billing input vectors. For EOR (Employee Receipt and Receipt) transactions, the input vector may include employee ID, employee country, billing period, salary, employer cost, service fee base, start and end dates, and tax calculation method. For Payroll transactions, the input vector may include number of employees, payroll batches, one-time fees, and additional service items. For settlement transactions, the input vector may include accounts receivable, expense reimbursement items, security deposits, VAT, and WHT.

[0063] The system calculates the charge amount line by line for each charge item and outputs a detailed customer statement. Each line of detail includes the charge item name, charge type, charge rule text, charge amount, charge currency, contract configuration code, charge item version number, contract evidence identifier, parsed evidence identifier, manual confirmation identifier, calculation formula, calculation result, exception status, and source hash.

[0064] Source hash can be represented as Where BillLineSet is the set of billing line items, RuleSnapshot is the snapshot of the target billing rule version, ContractEvidence is the set of contract evidence relationships, ParseEvidence is the set of parsed evidence, ManualConfirm is the set of manual confirmation records, and CalcSnapshot is the snapshot of the calculation process.

[0065] By using source hashing, the system can detect whether the expense lines, rule versions, evidentiary relationships, manual confirmation records, or calculation processes on the statement of account have been subsequently tampered with. When a customer questions a certain expense, business personnel can trace back to the contract terms, quotation source fragments, manual confirmation records, and calculation process snapshots from the statement of account details, without having to manually search through multiple contract attachments.

[0066] For historical billing period recalculation requests, the system reads the corresponding historical version snapshot based on the billing period, rather than reading the latest current configuration. If the current contract document has been updated or the current pricing rules have changed, the historical recalculation will still use the charging parameters, contractual evidence relationships, parsing sources, and manual confirmation records from the historical snapshot.

[0067] During historical recalculation, the system first locates the contract configuration version and billing item version that were in effect at the time of the billing period. Then, it reads the contract evidence relationships, parsing sources, manual confirmation records, and calculation parameters from the snapshot of that version. If the current latest version has changed the billing amount or the contract file has been replaced, the system still uses the parameters and evidence fingerprints from the historical version snapshot for calculation and marks the historical version as recalculated in the recalculation result.

[0068] After recalculation, the system compares the newly generated statement traceability hash with the original statement traceability hash. If the amount and traceability hash are the same, the system marks it as a complete reproduction; if the amount is the same but the traceability hash is different, the system indicates that the evidence or parsing source may differ; if the amount is different, the system outputs the difference amount, difference fields, difference version, difference evidence, and a list of affected employees.

[0069] The system can also categorize historical recalculation discrepancies into differences in fee amount, currency, tax calculation method, evidentiary fingerprint, manual confirmation, and calculation input. By classifying these discrepancies, auditors can quickly determine whether they originate from contract version, quotation parsing, manual processing, or business input data.

[0070] like Figure 7 As shown, the system performs multiple anomaly checks during configuration maintenance and bill generation. For billing items lacking supporting contract evidence, the system marks them as lacking evidence and prevents them from entering the automatic activation state; for situations where multiple valid billing rules exist for the same fee type, business type, employee nature, and billing period, the system marks them as rule conflicts; and for cases where the billing model is tiered but lacks tier boundaries, the system marks them as incomplete parameters.

[0071] Abnormal tasks enter the configuration review queue. The review queue displays the exception type, affected customers, affected countries or regions, affected business type, affected billing period, candidate rules, source of evidence, suggested handling method, and blocking level. After the reviewer handles the task, the system records the handler, handling time, handling conclusion, and handling basis. If the handling conclusion changes the version of the billing item, the system creates a new version snapshot; if the handling conclusion only changes the manual confirmation status, the system updates the confirmation record but does not overwrite the original parsing source.

[0072] The system generates audit logs, which include events such as importing quotation sources, parsing fields, manual confirmation, binding contract evidence, version activation, rule selection, cost calculation, reconciliation statement output, historical recalculation, and anomaly audits. Each audit event includes the operator, operation time, operation object, summary before change, summary after change, event type, and event hash.

[0073] In one implementation, each event is written to the `prevEventHash` field, which references the hash of the previous event, thus forming an event chain. If any historical event is tampered with, subsequent event chain verifications will fail. This mechanism improves the reliability of contract configuration and billing processes.

[0074] In one specific implementation, the customer statement module invokes the method of the present invention through a real-time value retrieval interface. The real-time value retrieval interface receives the customer identifier, country or region identifier, business type, employee nature, fee type, billing period, and billing input vector. The system returns the target charging rule version, charging amount, currency, associated contract evidence, parsing source, manual confirmation record, calculation formula, and traceability hash.

[0075] For rule pre-validation requests, the system performs checks for missing evidence, version range, currency consistency, completeness of fee mode parameters, inheritance strategy, and rule conflict before the customer's statement is generated. If any check fails, the system returns the exception type, scope of impact, candidate rules, source of evidence, and suggested action.

[0076] For batch API calls, the system supports paginated submissions, asynchronous execution, and retrying for failed groups. Batch tasks include fields such as batchId, requestGroupId, customerId, countryCode, businessType, billingPeriod, status, errorCode, and outputFileId. The system writes the group status after each group is completed, allowing for the retention of successful results even in cases of partial failures in large-scale bill generation, and permitting re-execution for failed groups.

[0077] During batch task execution, the system groups tasks by customer, country or region, business type, and billing period, and then reads the corresponding contract configuration tree node and version snapshot for each group. If a group has rule conflicts or missing evidence, the system only prevents that group from automatically generating billing statements, without affecting other groups without issues from continuing to generate statements.

[0078] like Figure 6As shown, in a data association structure, there is a one-to-many relationship between the quotation source object and the candidate quotation field object; a many-to-one or one-to-one relationship between the candidate quotation field object and the structured fee item object; a one-to-many relationship between the structured fee item object and the fee item version object; and a many-to-many relationship between the fee item version object and the contract evidence relationship object, the parsed evidence relationship object, and the manual confirmation record object.

[0079] A reference relationship is established between the statement details object and the charge item version object, contract evidence relationship object, parsing evidence relationship object, manual confirmation record object, and calculation process snapshot object. This association structure enables the system to trace back from any statement expense line to the charge item version, contract configuration node, contract document, quotation source fragment, manual confirmation task, and original parsing result.

[0080] To avoid data loss, when deleting, replacing, or invalidating a contract document, the system does not delete existing historical evidence relationships, but instead adds a new record of evidence status changes. The historical evidenceId referenced in the statement of account can still read the original evidence fingerprint, source fragment hash, and the evidence status at that time. If the original document is archived due to compliance requirements, the system can retain the file hash and fragment hash as lightweight proof and restore the corresponding file from the archived system when needed.

[0081] To further illustrate the feasibility of this invention, the following example uses Client A's EOR business in Singapore and Malaysia. Client A's framework agreement stipulates a monthly payment cycle, a default currency of USD, and a minimum monthly management fee of USD 1,000; the Singapore contract stipulates a service fee of 8% of the employer's costs, while the Malaysian contract stipulates a fixed service fee of USD 300 per employee, and the Singapore contract appendix includes a screenshot supplementing the agreement with a one-time onboarding fee for the first month.

[0082] After receiving the above materials, the system generates sourceIds for the framework agreement, national contract, screenshot attachments, and email confirmation. The framework agreement text enters the text parsing channel, and the system recognizes fields such as "monthly payment term" and "minimum monthly management fee"; the Singapore national contract enters the text parsing channel, and the system recognizes "8% of employee cost"; the Malaysian quotation enters the table parsing channel, and the system recognizes the fixed amount at the employee level; the screenshot attachments enter the OCR parsing channel, and the system recognizes the one-time onboarding fee amount and its corresponding coordinate range.

[0083] The field standardization module maps the minimum monthly management fee in the framework agreement to a minimum fee constraint, the 8% of employer cost in the Singapore national contract to a proportional fee model, the peremployee monthly fee in the Malaysian quotation to a fixed amount model, and the onboarding fee in the screenshot to a one-time fee. Regarding the screenshot source, since the OCR confidence level is 0.82 and below the automatic activation threshold of 0.90, the system generates a pending confirmation task.

[0084] After the reviewer opens the task to be confirmed, they can see the original screenshot, OCR candidate results, suggested fields, page number or coordinate range, source fragment hash, and affected business lines. Once the reviewer confirms that the screenshot is indeed for Customer A's first month's onboarding fee in Singapore, the system generates a manualConfirmId and binds this confirmation record to the snapshot of the one-time onboarding fee's version.

[0085] The hierarchical configuration module generates a framework agreement configuration node, an SG country contract configuration node, and a MY country contract configuration node for customer A. The payment cycle field is marked as inheritable, so both the SG and MY country nodes can inherit the monthly settlement settings of the framework agreement; the service fee field is marked as a country-specific field, so the SG node uses a proportional service fee, and the MY node uses a fixed amount service fee, and neither can inherit the service fee amount from the framework agreement.

[0086] When the SG billing request for the March 2026 billing period arrives, the request will include customerId=A, countryCode=SG, businessType=EOR, billingPeriod=2026-03, employeeId, employeeCost, and fee type. The system will locate the SG country contract configuration node, filter candidate service fee rule versions, and calculate a score based on the effective billing period, evidence validity status, and manual confirmation status. Once the SG service fee version is matched, the billing kernel will calculate the service fee by multiplying employeeCost by 8%.

[0087] When a billing request from MY arrives within the same billing period, the system locates the MY country contract configuration node and matches the fixed-amount service fee version. Since MY service fees are billed per employee, the system generates a detailed fee statement line by line based on the employee list. Each line records the employeeId, the billing item version number, the contract evidence identifier, the calculation formula, and the traceHash. If an employee joins midway through the billing period, the system can apply either a daily or monthly pro-rata calculation rule based on the start date in the billing input vector.

[0088] For Customer A's one-time onboarding fee for the first month in Singapore, the system checks the fee type as a one-time fee when selecting rules and reads the manually confirmed record. If the confirmation record is still valid, the billing is allowed; if the confirmation record has expired or been withdrawn, the system generates a pending review exception and does not automatically generate the fee line. This prevents screenshot-based quotes from continuing to affect the billing even after confirmation has expired.

[0089] When Client A requested a review of the March 2026 invoice, the salesperson entered the traceHash from the invoice line, and the system reversed the process to retrieve the ruleVersionId, evidenceId, parseEvidenceId, manualConfirmId, and calcSnapshotId. The system was able to display the relevant SG country contract terms, screenshot attachment coordinates, manual confirmation records, employer cost input, and the 8% percentage calculation process. This review process did not require manual review of all contract documents.

[0090] If Customer A signs a supplemental agreement in May 2026, adjusting the SG service fee from 8% to 7.5%, the system will not overwrite the 8% version effective in March 2026. Instead, a new 7.5% version will be added, and the effective and expiration dates of the 8% version will be updated to the day before the supplemental agreement takes effect. The 7.5% version will be used when generating the June 2026 bill, while the historical 8% version will still be used when recalculating the March 2026 bill.

[0091] In terms of data storage, the system can store quotation source objects, candidate field objects, structured charging item objects, charging item version objects, evidence relationship objects, manual confirmation objects, calculation snapshot objects, and bill detail objects in relational databases, document databases, or object storage, respectively. Reference relationships are established between objects through stable identifiers, and hash fields are used to verify whether referenced objects have changed.

[0092] Regarding access control, the system can assign different permissions to parsing, confirmation, activation, billing, and historical recalculation. Personnel with parsing permissions can only view the parsing results; personnel with confirmation permissions can process tasks awaiting confirmation; personnel with activation permissions can submit versions of chargeable items; business systems with billing permissions can only read activated versions; and personnel with auditing permissions can view event chains and historical snapshots.

[0093] Regarding anomaly recovery, if a batch billing task fails due to missing evidence for a particular country group, the system records the failed group, the reason for failure, candidate rules, and suggested actions; other country groups continue to generate reconciliation statements. Once the auditors have supplemented the evidence or confirmed the rules, the system can re-execute only for the failed group without regenerating the results of the already successful groups.

[0094] In terms of performance, the system can pre-index customer identifiers, country or region identifiers, business types, fee types, and version validity ranges. For batch billing requests, the system first groups by customer and country, then caches the corresponding contract configuration tree and effective version snapshot, allowing multiple employees within the same group to share the rule selection results. The billing kernel function is executed only for employee-level input, thereby reducing duplicate matching.

[0095] In terms of security implementation, the system uses the same hash algorithm or a configurable hash algorithm for contract document hashing, source fragment hashing, event hashing, and account statement tracing hashing. The hash algorithm can be SHA-256 or other algorithms that meet enterprise security requirements. When displaying contract source fragments, the system can anonymize personal information other than amounts based on permissions, balancing customer dispute resolution and data protection requirements.

[0096] As can be seen from the above end-to-end example, this invention not only saves contract configuration fields, but also combines multimodal quotation parsing, field standardization, hierarchical inheritance, evidence binding, version snapshot, rule selection, billing calculation, anomaly review and source tracing review into a continuous technical process, which can support automated reconciliation statement generation in multiple countries, multiple business lines and multiple billing periods.

[0097] The present invention also provides a device for automatically generating customer account statements, the device comprising a quotation parsing module, a field standardization module, a hierarchical configuration module, an evidence binding module, a version management module, a rule selection module, a billing calculation module, an account statement generation module, an anomaly review module, a business value retrieval interface module, and an audit tracking module.

[0098] The quotation parsing module analyzes customer contract text, contract attachments, quotation forms, email quotation text, screenshot quotations, scanned quotations, and manually entered quotations, and outputs a set of candidate quotation fields. The field standardization module generates a structured set of fee items based on a field dictionary, a thesaurus, and validation rules. The hierarchical configuration module generates unique keys for contract configurations and constructs a customer contract configuration tree.

[0099] The evidence binding module maintains the contractual evidentiary relationship between chargeable items and customer contract documents, quotation source fragments, or manual confirmation records. The version management module generates contract configuration version snapshots and chargeable item version snapshots. The rule selection module determines the target charging rule version based on value requests from the business system. The billing calculation module generates detailed cost breakdowns based on multi-mode billing kernel functions.

[0100] The statement generation module outputs customer statement details, target charging rule versions, contract evidence relationships, parsed evidence relationships, manual confirmation records, and calculation process snapshots. The anomaly audit module handles issues such as insufficient parsing confidence, rule conflicts, missing evidence, currency anomalies, incomplete parameters, and version range anomalies. The business value retrieval interface module provides real-time value retrieval, batch value retrieval, rule pre-validation, and historical account period recalculation capabilities to EOR, Payroll, settlement, and other business processes. The audit trail module generates audit event chains and source hashes.

[0101] The present invention also provides a computer device, including a processor, a memory, a communication interface, and a computer program stored in the memory. When the computer program is executed by the processor, it implements the steps in the above method embodiments. The processor may be a general-purpose processor, a special-purpose processor, a graphics processor, or a multi-core processor; the memory may be volatile memory, non-volatile memory, or a combination thereof.

[0102] The present invention also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, it implements the steps in the above method embodiments. The computer-readable storage medium may include a magnetic disk, optical disk, read-only memory, random access memory, flash memory, solid-state drive, removable storage medium, or network storage medium.

[0103] It should be understood that the above embodiments are merely examples for illustrating the technical solutions of the present invention and do not constitute a limitation on the scope of protection of the present invention. Those skilled in the art can combine, replace, or make equivalent modifications to the modules, steps, fields, scoring models, billing kernel functions, and data structures in the above embodiments without departing from the concept of the present invention, and all such modifications should fall within the scope of protection of the present invention. Attached Figure Description

[0104] Figure 1 This is a schematic diagram of the overall process of the automatic generation method for customer statements provided in an embodiment of the present invention.

[0105] Figure 2 This is a schematic diagram of a customer contract configuration tree provided for an embodiment of the present invention.

[0106] Figure 3 This is a schematic diagram of the multimodal quotation analysis process provided in an embodiment of the present invention.

[0107] Figure 4 This is a schematic diagram of the snapshot structure of the paid item version provided in an embodiment of the present invention.

[0108] Figure 5 This is a schematic diagram of the rule selection and billing calculation process provided in an embodiment of the present invention.

[0109] Figure 6 This is a schematic diagram of the data object association structure provided in an embodiment of the present invention.

[0110] Figure 7 This is a schematic diagram of the abnormal review and audit event chain provided in an embodiment of the present invention.

Claims

1. A method for automatically generating customer account statements based on hierarchical contract configuration and multimodal quotation parsing, characterized in that, include: S1. Obtain customer contract configuration requests and quotation source data. The quotation source data includes at least one of the following: contract text, contract attachments, quotation form, email quotation text, image quotation screenshot, scanned quotation, and manually entered fields. S2. Perform multimodal quotation parsing on the quotation source data, outputting a candidate quotation field set containing the original field name, original field value, standard field name, standard field value, source file identifier, source page number or layout coordinates, source fragment hash, parsing channel identifier, parsing time, and parsing confidence level. S3. Based on a field dictionary, synonym mapping table, fee type enumeration, charging mode enumeration, currency dictionary, country or region dictionary, and verification rules, standardize, perform conflict verification, and manually confirm and write back the candidate quotation field set to generate a structured fee item set. S4. Based on customer identifier, country or region identifier, tenant, or system... S5. Construct a customer contract configuration tree containing framework protocol configuration nodes and country contract configuration nodes, based on namespace, contract scope of application, contract status, and field inheritance strategy; S6. Establish contract evidence relationships, parsing evidence relationships, manual confirmation records, and fee item version snapshots for the fee items in the structured fee item set; S7. Receive value requests from the business system and determine the target fee rule version in the customer contract configuration tree based on the customer identifier, country or region identifier, business type, employee nature, fee type, billing period, and billing input vector in the value request; S8. Call the corresponding billing kernel function to generate customer statement details based on the target fee rule version; S9. Associate and output the target fee rule version, contract evidence relationships, parsing evidence relationships, manual confirmation records, calculation process snapshots, and customer statement details, and generate a traceability hash for review.

2. The method according to claim 1, characterized in that, The multimodal quotation parsing includes: performing paragraph segmentation, clause number recognition, key phrase recognition, amount expression recognition, effective range recognition, and context window extraction on text documents; performing header recognition, merged cell expansion, row and column semantic normalization, currency column recognition, fee cycle recognition, and remarks column parsing on table files; performing OCR recognition, row block reconstruction, column block reconstruction, page coordinate binding, and low confidence interception on image quotation screenshots or scanned copies; performing joint parsing of subject, sender, recipient, sending time, quotation fragments in the body, and attachment list on email quotation text; and performing field format validation and source supplementation validation on manually entered fields.

3. The method according to claim 1, characterized in that, Standardizing the candidate quotation field set includes: retaining the original field name and original field value for each candidate field; mapping service fee, management fee, monthly service fee, and service charge to a unified fee type; mapping fixed, flat amount, and fixed amount to a fixed amount pattern; mapping percentage, rate, and proportional to a proportional pattern; mapping tier, ladder, and tiered fees to a tiered pattern; and performing format validation on the amount field, percentage field, date field, currency field, billing cycle field, and tax field respectively.

4. The method according to claim 1, characterized in that, When the resolution confidence level is lower than a preset threshold, there are multiple candidate amounts in the same quotation source, the currency is missing, the effective period of the fee items overlaps, the fee model and parameters do not match, the contract evidence is missing, the manual confirmation record is expired, or the applicability relationship between the framework agreement configuration and the national contract configuration cannot be determined, a pending confirmation task is generated. The pending confirmation task displays the original source fragment, candidate resolution results, suggested standard fields, conflict reasons, impact on payment period and optional processing actions, and generates a new fee item version snapshot after confirmation.

5. The method according to claim 1, characterized in that, The customer contract configuration tree uses a unique contract configuration key. Generate, where C represents the customer identifier, N represents the country or region identifier, and S represents the tenant or system namespace; and pass a unique constraint function. Only one valid contract configuration node exists for the same tenant, the same customer, the same country or region within the same valid time interval, where T represents the valid time interval.

6. The method according to claim 1, characterized in that, The customer contract configuration tree supports field inheritance strategies, which include prohibiting inheritance, allowing inheritance, displaying inheritance only, and requiring review of inheritance. When the national contract configuration node does not have a target field configured and the target field allows inheritance, the field value is read from the framework protocol configuration node. When a target field is marked as a country-specific field, inheritance from the framework protocol configuration node is prohibited; when a target field is marked as requiring review for inheritance, the inherited value enters the pending confirmation task and does not participate in automatic billing before confirmation.

7. The method according to claim 1, characterized in that, The structured fee items include customer identifier, country or region identifier, business line, employee nature, fee type, fee item name, fee model, fee amount, fee ratio, tier boundary, tier billing base, minimum fee, maximum fee, currency, tax caliber, effective start time, effective end time, contract evidence identifier, parsed evidence identifier, manual confirmation identifier, and version status.

8. The method according to claim 1, characterized in that, The contract evidence relationship includes contract document identifier, contract name, contract status, signing entity, clause location, attachment page number, source fragment hash, upload time, evidence validity status, and evidence fingerprint; when the contract document expires, is replaced, becomes invalid, or is archived, the evidence fingerprint in the historical paid item version snapshot is retained, and a new record of evidence status change is added.

9. The method according to claim 1, characterized in that, Creating version snapshots for paid projects includes: when adding a new paid project version, updating the effective end time of the previous paid project version to a preset time boundary before the effective start time of the new paid project version, forming non-overlapping version time intervals; prohibiting overwriting modifications to already effective versions, and allowing editing of draft versions that have not yet taken effect, but generating a commit snapshot and event hash when committing to take effect.

10. The method according to claim 1, characterized in that, Determining the target charging rule version includes scoring based on priority. Sort the candidate charging rule versions; among them This indicates the hit score for the contract configuration level. This indicates the score that matches the valid range of the billing period and version. The score indicates the validity of the evidence. This indicates the matching score based on the business dimension. This indicates the quality score of the quote parsing or the quality score of the manual confirmation. When there are multiple candidate versions with the highest score, the target charging rule version is determined in the following order: national contract configuration takes precedence over framework agreement configuration, manual confirmation takes precedence over automatic parsing, and the most recently effective version takes precedence over the earlier version.

11. The method according to claim 1, characterized in that, The billing kernel function includes a fixed amount kernel function, a proportional kernel function, a fixed amount tiered kernel function, a proportional tiered kernel function, a minimum charge kernel function, a maximum charge kernel function, and a tax surcharge kernel function; when the charging mode is a proportional tiered mode, the billing kernel function satisfies Where z represents the step index, and This represents the q-th step boundary. This represents the q-th step ratio. This represents the billing base for the q-th tier.

12. The method according to claim 1, characterized in that, Generating customer statement details involves mapping at least one input item from EOR, Payroll, and Settlement transactions—including employee, payment period, salary, annual salary, employer costs, service fees, one-time fees, reimbursement service fees, security deposit, VAT, and WHT—to a billing input vector. For each expense item, the calculation of the charge amount is performed line by line, and the output includes the charge item name, charge type, charge rule text, charge amount, currency, contract configuration code, charge item version number, evidence identifier, calculation formula, calculation result, exception status, and source hash.

13. The method according to claim 1, characterized in that, The value retrieval requests include real-time value retrieval requests, batch bill generation requests, rule pre-validation requests, and historical billing period recalculation requests. For historical billing period recalculation requests, the corresponding historical version snapshot is read according to the billing period, and the use of the latest current configuration to replace the historical snapshot is prohibited. For rule pre-validation requests, evidence missing verification, version range verification, currency consistency verification, fee mode parameter integrity verification, inheritance strategy verification, and rule conflict verification are performed before the customer generates the bill.

14. A device for automatically generating customer account statements based on hierarchical contract configuration and multimodal quotation parsing, characterized in that, The device includes a quotation parsing module, a field standardization module, a hierarchical configuration module, an evidence binding module, a version management module, a rule selection module, a billing calculation module, a statement generation module, an anomaly review module, a business value retrieval interface module, and an audit tracking module; the device is used to execute the method described in any one of claims 1 to 13.

15. A computer device comprising at least one processor and at least one memory, wherein the at least one memory stores a computer program, characterized in that, When the computer program is executed by the at least one processor, it implements the method according to any one of claims 1 to 13.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 13.

Images