Variance management systems and methods for generating resource calculations

Abstract

Variance management systems and methods for generating resource calculations are described. In some examples, an item in a transaction may be classified at the time of the transaction. A resource calculation may be generated based on the classification. Another resource calculation may be generated using a classification made after the transaction. Ultimately, a resource calculation may be made by a third party and assessed. There may be variance between these resource calculations. Examples described herein modify resource calculations to manage variance.

Description

VARIANCE MANAGEMENT SYSTEMS AND METHODS FOR GENERATING RESOURCE CALCULATIONSCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit under 35 U.S.C. § 119(e) of the earlier filing date of U.S. provisional application serial number 63 / 587,416, filed October 2, 2023, which provisional application is hereby incorporated by reference in its entirety for any purpose.BACKGROUND

[0002] Online Software Platforms (OSPs) are often operated by online service providers.

[0003] Online Software Platforms typically receive data from clients of the online service providers, and perform actions with the data that are useful to the clients.

[0004] When businesses sell or buy goods, they are required by law to compute the amount of money they may owe as taxes and / or duties to various tax jurisdictions, and then remit these amounts to the tax jurisdictions. If they fail to accurately report and remit taxes, they may be subject to audits and fines; ignorance of the law is not an excuse for failure to comply. Moreover, determining the taxes and / or duties due may be very complex. In cross- border e-commerce, when goods clear customs, it may typically be the customs brokers that pay the various importation fees upfront. Usually, service may be included in transportation from major carriers. The online retailer may receive the invoice from the carrier / broker to pay them back. There may be additional fees (e.g., brokerage fees) which are charged to cover this service.

[0005] Businesses generally collect information relating to their operations and transactions, such as by using enterprise resource planning (ERP) software applications and accounting applications. ERP applications manage information relating to a business's activities, such as sales, resource management, production, inventory management, delivery, billing, and so on. Accounting applications manage a business’s accounting information, such as purchase orders, sales invoices, payroll, accounts payable, accounts receivable, and so on. However, ERP applications, accounting applications, e-commerce applications, and other conventionally used applications fail to provide accurate, reliable per-jurisdiction tax compliance information for their cross-border sales needs, including estimated taxes due in a proposed transaction, in a timely and efficient manner according to the various different rules in various different tax jurisdictions.

[0006] As one example, the Harmonized Commodity Description and Coding System (HS) is an international nomenclature for the classification of products that may typically allow participating countries to classify traded goods on a common basis for customs purposes. The HS defines codes, also known as HS codes, for a very large fraction of all items traded internationally. Most customs authorities require HS codes to be provided on import and export declarations.

[0007] HS codes are numerical codes of at least six digits that describe what is being shipped to and from countries worldwide; the first two numbers define a “Chapter,” the second two a “Heading,” and the last two a “Subheading.” For instance, HS Code 850870 may define “parts of vacuum cleaners.” However, HS codes may change at least every five years. The first six digits of the HS code are common to all countries. Beyond those, each country is permitted to add additional numbers to suit its own tariff and statistical needs, creating 8-, 10-, and sometimes 12-digit national codes. Such national tariff codes may also change, sometimes several times per year.

[0008] In most countries, the importer of record is solely responsible for the accuracy of the HS codes declared to customs. Improper HS classification can result in overpayment of customs due, which reduces profits, or in underpayment, which can result in penalties. However, it will be appreciated that in a variety of circumstances, such HS codes may be unavailable or difficult to determine, especially in jurisdictions for which the available descriptions of various products and services may be ambiguous or lacking.SUMMARY

[0009] Examples of methods are described herein. In some examples, a method may include generating, by a quoting system, a first resource calculation for an instance associated with an item and a jurisdiction. The first resource calculation may use a first classification of the item. The method may include receiving, at the quoting system, a second classification of the item. The method may further include generating, by the quoting system, a second resource calculation for the instance associated with the item and the jurisdiction. The second resource calculation may use the second classification of the item. The method may include calculating, by the quoting system, a simulated variance between the first resource calculation and the second resource calculation. The method may include generating, by the quoting system, and based on the simulated variance, a coefficient for use in calculating a subsequent resource calculation for a subsequent instance associated with the item and the jurisdiction.

[0010] In some examples, methods may further include adjusting, by the quoting system, the coefficient based on an estimated impact of the coefficient on a number of subsequent resource calculations.

[0011] In some examples, adjusting may include calculating, by the quoting system, a sensitivity score based, at least in part, on a volume of expected instances of the item and the jurisdiction.

[0012] In some examples, adjusting may include adjusting the coefficient by an amount based, at least in part, on the sensitivity score.

[0013] In some examples, methods may further include notifying, by the quoting system, a user when the sensitivity score exceeds a threshold.

[0014] In some examples, methods may further include receiving, from the user, a response to said notifying, and the adjusting may further be based on the response.

[0015] In some examples, generating the first resource calculation may include using machine learning to generate the first resource calculation.

[0016] In some examples, generating the second resource calculation may include receiving the second classification from a secondary system.

[0017] In some examples, methods may further include receiving, at the quoting system, a third resource calculation for the instance associated with the item and the jurisdiction, and calculating, by the quoting system, an actual variance between the first resource calculation and the third resource calculation. In some examples, generating the coefficient may be further based on the actual variance.

[0018] In some examples, methods may further include generating a key for the first resource calculation and utilizing the key, at the quoting system, to associate the first resource calculation with the third resource calculation.

[0019] In some examples, methods may further include performing the subsequent resource calculation, and displaying a result of the subsequent resource calculation.

[0020] Examples of computer readable media are described herein. In some examples, at least one computer readable media is encoded with instructions which, when executed by one or more processors, cause a computing system to perform operations. The operations may include generating a first resource calculation for an instance associated with an item and a jurisdiction. The first resource calculation may use a first classification of the item. The operations may include receiving a second classification of the item. The operations may include generating a second resource calculation for the instance associated with the item andthe jurisdiction. The second resource calculation may use the second classification of the item. The operations may include calculating a simulated variance between the first resource calculation and the second resource calculation. The operations may include generating, based on the simulated variance, a coefficient for use in calculating a subsequent resource calculation for a subsequent instance associated with the item and the jurisdiction.

[0021] In some examples, the operations may further include adjusting the coefficient based on an estimated impact of the coefficient on a number of subsequent resource calculations.

[0022] In some examples, said adjusting may include calculating a sensitivity score based, at least in part, on a volume of expected instances of the item and the jurisdiction.

[0023] In some examples, said adjusting may include adjusting the coefficient by an amount based, at least in part, on the sensitivity score.

[0024] In some examples, the operations may further include notifying, by the quoting system, a user when the sensitivity score exceeds a threshold.

[0025] In some examples, the operations may further include receiving, from the user, a response to said notifying, and said adjusting may be further based on the response.

[0026] In some examples, said generating the first resource calculation may include using machine learning to generate the first resource calculation.

[0027] In some examples, said generating the second resource calculation may include receiving the second classification from a secondary system.

[0028] In some examples, the operations may further include receiving a third resource calculation for the instance associated with the item and the jurisdiction, and calculating an actual variance between the first resource calculation and the third resource calculation. Generating the coefficient may be further based on the actual variance.

[0029] In some examples, the operations may further include generating a key for the first resource calculation, and utilizing the key to associate the first resource calculation with the third resource calculation.

[0030] In some examples, the operations may further include performing the subsequent resource calculation, and displaying a result of the subsequent resource calculation.BRIEF DESCRIPTION OF THE DRAWINGS

[0031] FIG. 1 is a schematic illustration of a system, arranged in accordance with examples described herein.

[0032] FIG. 2 is a schematic illustration of a system arranged in accordance with examples described herein.

[0033] FIG. 3 is a flowchart illustrating an example method for measuring variance arranged in accordance with examples described herein.

[0034] FIG. 4 is a schematic illustration of variance data and a process for coefficient generation arranged in accordance with examples described herein.

[0035] FIG. 5 is a schematic illustration of a user interface displaying a variance dashboard in accordance with examples described herein.

[0036] FIG. 6 is a flowchart illustrating a method for calculating conversion sensitivity scores arranged in accordance with examples described herein.

[0037] FIG. 7 is a flowchart illustrating a method for adjusting and implementing coefficients in accordance with examples described herein.

[0038] FIG. 8 is a schematic illustration of a system arranged in accordance with examples described herein.

[0039] FIG. 9 is a schematic illustration of the operation of digital tax rules arranged in accordance with examples described herein.DETAILED DESCRIPTION

[0040] Variance management systems and methods for generating resource calculations are described. In some examples, an item in a transaction may be classified at the time of the transaction. A resource calculation may be generated based on the classification. Another resource calculation may be generated using a classification made after the transaction. Ultimately, a resource calculation may be made by a third party and assessed. There may be variance between these resource calculations. Examples described herein modify resource calculations to manage variance.

[0041] Various approaches for estimating taxes and duties associated with cross-border transactions may rely on several detailed input parameters to perform various calculations. While several of these parameters may be available for one or more items being sold (e.g., price, shipping cost), others may not (e.g., HS code, tax code, HS code-specific parameters); alternatively or in addition, a customer may not possess the necessary knowledge and / or resources to know what associated parameters are, or whether they apply to the customer’s transactions. Therefore, existing approaches may be unable to calculate the associated taxes and duties for items or services being sold.

[0042] For example, consider a merchant who has 100,000 items in their catalog and wants to be able to sell them in a large number of international destination zones (such as 100 or more countries, customs unions, or other jurisdictions). Various existing approaches mayrequire that the merchant communicate a complete HS code to a computing system for each item in their transaction, along with specific input parameters (per HS code), in order to allow the computing system to calculate the associated taxes and duties. Because the complete HS code is likely different in each jurisdiction, the merchant would have to request or determine multiple classifications per item (e.g.. one per jurisdiction, such as 100 jurisdictions in one example). As a result, the merchant would have to identify 10 million classifications for their 100,000 items and communicate millions of classification codes individually to any computing systems performing tax calculations. This volume of classifications and classification code determination and calculation is not practical for merchants to determine. In addition, merchants may also have to determine and provide the unique parameters and tax codes for each item. This exercise is costly and time consuming, likely prohibiting the merchant from using existing approaches to satisfy their cross-border sales needs.

[0043] A variety of techniques or systems may be used to estimate the HS code and / or otherwise estimate duty and / or tax due at a time of a transaction (e.g., an online sales transaction), including utilizing artificial intelligence and / or machine learning techniques in accordance with one or more pricing strategies. However, these estimates may be incorrect to varying degrees. After some amount of time, it may be possible to obtain a more accurate HS code (e g., using expert classifiers) and / or to obtain other information relevant to the transaction that may have been missing and / or inaccurate at the time of the initial tax and duty estimate. There may exist a simulated variance between the estimated tax and duty calculation and a subsequent tax and duty calculation performed with additional and / or updated information.

[0044] Moreover, ultimately, customs documentation (e.g.. commercial invoices and / or manifests) may reflect an actual amount of tax and / or duty charged for a particular transaction. This actual amount of tax and / or duty may be different than the amount estimated at the time of the transaction, and may also be different than a calculation performed after the transaction using additional or updated information. There may exist an actual variance between the amount of tax and / or duty assessed by a jurisdiction as a result of a transaction and one or more estimates of that tax and / or duty.

[0045] These variances - both simulated variances and actual variances - may reflect risk to a seller entity. If the variances are too large in one direction (customers are being charged excessive estimated tax and / or duty at a time of transaction), then there may be a loss in sales due to increased pricing associated with the transaction. If the variances are too large in another direction (customers are being undercharged relative to the actual tax and / or dutyassessed), then there may be an economic loss to the seller if they are responsible for paying the additional tax and / or duty. Accordingly, it may be advantageous to control variances involved in tax and / or duty calculations.

[0046] Examples described herein may wholly address a problem of financial risk exposure caused by the discrepancy between invoiced importation fees from customs authorities and the original checkout estimates. Examples described herein may use a continuous automated feedback loop combined with conversion risk techniques to optimize the implementation of corrective measures in estimated values. Computing architectures and methodologies are described that may efficiently address the discrepancy between initial estimates and actual incurred fees.

[0047] Generally, managing financial variance risk for entities that sell goods may be cumbersome and time consuming. For example, there may be over 200 countries supported for each seller, and managing country level quoting estimate changes that align more closely with invoice data for each customer would require Nx200 levels of analysis and implementation actions for N customers. This creates an obstacle for achieving scalability. The issue is further compounded by the need for a decision to be made for every customerjurisdiction combination for every iteration. The voluminous data preprocessing and reconciliation operations, again for every iteration, also pose an obstacle to scalability. These challenges make it difficult to achieve scalability using the human mind alone, and without implementing examples of systems and methods described herein for managing variance.

[0048] Therefore, current efforts for variance analysis are generally not scalable or fast enough to react to the signals such as invoice data or early warning signals from re-calculated estimates. The complexity of managing seller-level variance targets for each country (e.g., how closely estimates for their transactions over a time period should track their actual invoices), along with the human review used to ensure (or reduce a risk that) the recommended increases or decreases to each customer + country level dataset, will not jeopardize a seller’s checkout conversion. Moreover, not all changes to a process for calculating estimated tax and / or duty in order to manage variance may be desirable. In some examples, simply automating quoting changes without additional checks and balances, such as determining whether there was enough statistically relevant data, may make variance worse (e.g., use of a non-statistically significant dataset may cause premature corrections), and may also reduce checkout conversion (e.g., consummated transactions) with unrealistic changes (e.g.. when the estimated tax and / or duty is increased by over a threshold amount).

[0049] Examples described herein may provide systems and techniques to prevent or reduce changes in estimated tax and / or duty calculation that would impact customer checkout conversion beyond a threshold amount, yet in some examples only require approval (e.g., user review) for changes identified as exceeding a risk tolerance. This approach automates low- to medium-risk changes quickly using multiple algorithms and signals that can make smarter decisions faster at scale with minimum human intervention.

[0050] The present description includes examples of instances of Online Software Platforms (OSPs) that are operated by online service providers, for the benefit of clients of the online service providers (e.g., sellers).

[0051] In embodiments, an OSP receives data from a client (e.g.. a merchant) from its operations. The data is often provided in a single dataset. The data is associated with a domain taken from a plurality of domains.

[0052] In some embodiments, the OSP may operate one or more variance management systems that may control one or more quoting systems. The variance management systems may control the quoting systems to calculate resources in a manner to control an actual and / or simulated variance of the resource calculation. The OSP and / or variance management systems may in some examples implement guardrails to changes in the resource calculations. For example, controls which may have an estimated impact of greater than a threshold may receive further processing and / or review.

[0053] Examples of systems and methods described herein may accordingly advantageously provide efficient adjustment of resource calculations, while identifying adjustments that themselves should be adjusted to avoid estimated impacts greater than a threshold. Scaling these resource calculations and adjustments may involve particular storage, access patterns, and arrangements of data in order to allow adjustment of the resource calculations for large numbers of sellers with large numbers of items across large numbers of jurisdictions.

[0054] There can be also other advantages and / or benefits, and not all examples may exhibit all, or even any, of the described advantages, which are provided to facilitate understanding of example systems and methods described herein.

[0055] Variance management systems and methods for generating resource calculations are described. In some examples, an item in a transaction may be classified at the time of the transaction. A resource calculation may be generated based on the classification. Another resource calculation may be generated using a classification made after the transaction. Ultimately, a resource calculation may be made by a third party and assessed. There may bevariance between these resource calculations. Examples described herein modify resource calculations to manage variance.

[0056] FIG. 1 is a schematic illustration of a system, arranged in accordance with examples described herein. The system 102 includes a user system 104, a quoting system 106. a seller system 108, and a carrier system 110. The user system 104 includes computer system 112. The quoting system 106 includes computer system 114, quoting service 116, data 118, quoting application programming interfaces (APIs) 122, estimate data 124. datastore 126, variance data storage 128, and coefficient calculator 130. The computer system 114 may be used to implement quoting service 116, quoting APIs 122, datastore 126, and / or coefficient calculator 130. Storage in communication with the computer system 114 may be used to store data 118, estimate data 124, and / or variance data storage 128. The seller system 108 may include checkout process 134 and computing system 136. The computing system 136 may be used to implement the checkout process 134 in some examples. The carrier system 110 may include carrier data 138.

[0057] The components of FIG. 1 are exemplary. Additional, fewer, and / or different components may be used in other examples. For example, while some data storage devices are shown separately - e.g., data 118 and variance data storage 128 - it is to be understood that data described herein may be stored on a same storage device and / or spread across any number of storage devices. Additionally, while a single computer system 114 is shown in quoting system 106. generally any number of computing systems may be present to provide the described functionality for quoting system 106, user system 104, seller system 108, and / or carrier system 110.

[0058] Examples of systems described herein may include user systems, such as user system 104 of FIG. 1. Generally, a user system may include a computing system, such as computer system 112. The computer system 112 may include one or more processors and computer readable media encoded with instructions (e.g., software) which, when executed by the one or more processors, cause the user system 104 and / or computer system 112 to perform operations of a user system described herein. The user system 104 may facilitate input from a user to quoting system 106 in some examples. The user system 104 may present a user interface to a user for providing input to the quoting system 106 and / or receiving information from the quoting system 106. For example, the computer system 112 may include any number of input and / or output devices including one or more displays, keyboards, mice, speakers, microphones, and / or network interfaces. The user of the user system 104 may be a human user (e.g., an administrator or representative of a seller system) to provide data input to and / orreceive data output from the quoting system 106, examples of which are described herein. The user may in some examples be another software process. The user system 104 may be used during operation to access one or more dashboards or other data arrangements provided by the quoting system 106. The user system 104 may be used during operation to approve and / or modify suggested changes to calculations described herein, such as suggested coefficient changes.

[0059] Examples of systems described herein may include quoting systems, such as quoting system 106 of FIG. 1. Quoting systems described herein may generally be used to calculate resources associated with a transaction, such as duty and / or tax due. Quoting systems described herein may provide for the management of variance of resource calculations. The quoting system 106 may be in communication (e.g., wired or wireless communication, such as through one or more networks) with user system 104, seller system 108, and / or carrier system 110.

[0060] Quoting systems may include one or more computing systems, such as computer system 114 of FIG. 1. The computer system 114 may include one or more processors and computer readable media encoded with executable instructions (e.g., software), which, when executed by the one or more processors, cause the computer system 114 and / or quoting system 106 to perform operations described herein. The computer system 114 may include any number of input and / or output devices to communicate with the other systems and / or administrators. For example, the computer system 114 may include one or more displays, keyboards, mice, speakers, microphones, and / or network interfaces. In some examples, the quoting system may be hosted on a cloud service provider (e.g., AMAZON WEB SERVICES, GOOGLE CLOUD PLATFORM, or one or more other cloud service providers).

[0061] Examples of quoting systems described herein may provide a quoting service, such as quoting service 116 of FIG. 1. The quoting service 116 may be implemented as executable instructions encoded on computer readable media, which, when executed by one or more processors of the quoting system and / or another computing system, cause the computing system and / or quoting system to perform the described operations. In some examples, the quoting service 116 may be implemented by computer system 114. The quoting service 116 may generally receive information regarding an item, a jurisdiction, and / or a customer. The information regarding the item, jurisdiction, and / or customer may be received, for example, from seller system 108 and / or from data 118 stored in communication with quoting system 106. The quoting service 116 may generate a resource calculation (e g., may calculate a resource amount) for an instance (e.g., a transaction) associated with an item and ajurisdiction. In some examples, the instance may additionally be associated with a customer and / or consumer. The resource calculation may include an estimated amount of duty and / or tax to be applied to the instance (e.g., to the transaction). The quoting service 116 may classify the item in order to generate the resource calculation. The quoting service 116 may classify the item, for example, by assigning an HS code to the item. The quoting service 116 may classify the item based on information about the item (e.g., name, description, image, video) provided by the seller system 108 and / or data 118. The quoting service 116 may classify the item and generate a resource calculation at a time the transaction is requested. In this manner, the estimated resources provided by the quoting service 116 may be displayed to a customer and / or consumer in some examples prior to consummation of the transaction (e.g., prior to payment being received). After the transaction, the quoting service 116 may generate another resource calculation for the transaction using another classification of the item. For example, the quoting service 116 may access a post-transaction HS code which may be provided, for example, from one or more expert systems. The post-transaction HS code may be stored in some examples in data 118.

[0062] Examples of quoting systems may access stored data, such as data 118 of FIG. 1. The data may be stored in generally any computer readable storage, such as one or more memories, hard disk drives, flash memories, network storage, solid state drives, and / or data containers. The stored data may include, for example, data regarding items involved in transactions (e.g., item ID, item name, item description, item image, item video, and / or item price). The stored data may include data regarding jurisdictions, sellers, consumers, and / or transaction history.

[0063] Examples of quoting systems may include one or more interfaces for querying the quoting system such as quoting APIs 122 of FIG. 1. The quoting APIs 122 may be implemented using one or more APIs. The APIs may allow the seller system 108 to query the quoting system 106 to obtain a resource calculation for presentation to a consumer in a transaction. The quoting APIs 122 may provide estimated duty and / or tax calculations from the quoting system 106 to the seller system 108.

[0064] Examples of quoting systems may include stored estimate data, such as estimate data 124 of FIG. 1. The estimate data 124 may be stored in any storage media accessible to computer system 114, and may be stored together with data 118 and / or variance data storage 128 in some examples. The estimate data 124 may generally include tax and / or duty estimates calculated by quoting service 116 for transactions. The estimate data 124 may store dutyand / or tax estimates together with associated HS codes, transaction identifiers, item identifiers, consumer identifiers, jurisdictions, and / or seller identifiers.

[0065] Examples of quoting systems may include one or more datastores, such as datastore 126 of FIG. 1. Datastores may refer to storage combined with a computational query software, such as one or more data warehouses. In some examples, the computer system 114 may be used to implement some or all of the query software. In some examples, the datastore 126 may be implemented using one or more databases and may include extract, transform, and load (ETL) operations. In this manner, the datastore 126 may operate one or more ETL operations on data from other databases and / or sources to combine the data in the datastore 126. The combined data may include one or more resource calculations provided prior to transaction close (e.g., using a simulated HS code), one or more resource calculations provided after a transaction (e.g., using a post-transaction HS code), and / or actual resources (e.g., duties and / or taxes) charged by one or more carriers.

[0066] Examples of quoting systems may include variance data, such as variance data storage 128 of FIG. 1. The variance data may be implemented using generally any storage device accessible to the quoting system 106. The variance data storage 128 may be stored in some examples together with data 118 and / or estimate data 124. The variance data may include simulated variance data. The simulated variance data may refer to a difference between a resource calculation generated prior to transaction consummation and one generated after transaction consummation. For example, the simulated variance data may refer to a difference between a resource calculation using a simulated HS code and a resource calculation made using an HS code received from another system (e.g., an expert system) after the transaction. The variance data may include actual variance data. The actual variance data may be a difference between a generated resource calculation (either using pre- or posttransaction HS codes) and an actual resource charged, such as by a carrier and / or importer. The computer system 114 may be used to calculate the actual and / or simulated variance and may store the variance data in variance data storage 128.

[0067] Examples of quoting systems may include one or more calculators, such as coefficient calculator 130 of FIG. 1. The calculator may be implemented, for example, using computer system 114. For example, the computer system 114 may include memory' or other computer readable media storing executable instructions for calculating variance and / or coefficients for use in generating resource calculations. A processor of the computer system 114 may execute the instructions to perform actions described herein. During operation, the coefficient calculator 130 may access variance data storage 128 and may generate one or morecoefficients that may be used to bring variance within a threshold range for a particular item, jurisdiction, and / or seller. The coefficients may in some examples be stored, such as with variance data storage 128. The coefficients may be provided to and / or accessed by quoting service 116 and may be used to generate subsequent resource calculations for items, jurisdictions, and / or sellers. In this manner, the operation of quoting service 116 may be changed based on feedback related to a variance of the resource calculations. For example, the quoting service 116 may perform subsequent resource calculation(s) for an item using a coefficient. The coefficient may be used to adjust or otherwise alter a resource calculation. A result of a subsequent resource calculation made by the quoting service 116 may be displayed to a merchant and / or consumer, such as on a display of a computer system. The result may be used to collect a more accurate tax and / or duty from a consumer of the item.

[0068] Examples of systems described herein may include a seller system, such as seller system 108 of FIG. 1. The seller system 108 may be implemented, for example, using an online storefront. One or more computer systems may be used to provide seller system 108 and may provide a consumer with an interface to consummate a transaction. For example, the seller system 108 may include checkout process 134. The checkout process 134 may request a resource calculation (e.g., a duty and / or tax quote) from quoting system 106. For example, the checkout process 134 may call an API of the quoting APIs 122 to request a resource calculation. The quoting APIs 122 may return the result of the resource calculation, such as an estimated duty and / or tax amount. The estimate may be displayed to a consumer in the checkout process 134. and may be charged to the consumer when the transaction is consummated by the consumer. In some examples, the result of the resource calculation received by the seller system may be affected by a coefficient calculated in accordance with techniques described herein.

[0069] Examples of seller systems may include one or more computing systems, such as computing system 136 of FIG. 1, which may be a Systems Applications and Products (SAP) system (e.g., an ERP system). The computing system 136 may store enterprise data of the seller, for example, item data (e.g., item ID, item name, item description, item image, item video, item price, item quantity), consumer data (e.g.. consumer names, addresses, IDs, jurisdictions), and / or other enterprise information. In some examples, computing system 136 may include data regarding an actual amount of tax and / or duty charged by a third party, such as a carrier and / or importer. The actual tax and / or duty information may be provided by seller system 108 from computing system 136 to datastore 126 in some examples. One or more computing systems of the seller system 108 may be used to implement the communication of the actual duty information to the datastore 126. Recall that the actual duty' and / or taxamounts may be used to calculate actual variances to be stored in variance data storage 128 in some examples.

[0070] Examples of systems described herein may include one or more carrier systems, such as carrier system 110 of FIG. 1. When a transaction is consummated, the item may be delivered to the consumer. During the process of delivering the item to the consumer, one or more third parties (e.g., customs organizations, carriers) may calculate and charge an actual resource amount - e.g., an actual tax and / or duty. This actual amount charged may vary' from both pre- and post-transaction estimates of tax and / or duty described herein. The seller may be invoiced for the actual tax and / or duty amounts. For example, the carrier system 110 may include carrier data 138 which may include actual tax and / or duty amounts invoiced to the seller. In some examples, the carrier system 110 may provide the actual resource (e.g., actual tax and / or duty’ amounts) to the quoting system 106 (e.g., to the datastore 126). A computer system of the carrier system 110 may be used to provide the carrier data 138 to the quoting system 106.

[0071] During operation, the system 102 of FIG. 1 may accordingly be used to provide resource calculations (e.g., tax and / or duty amounts) to a seller. The manner in which the resource calculations are performed may be adjusted to control a variance associated with those amounts. In some examples, a user system, such as user system 104 of FIG. 1 may be used to provide one or more thresholds for variances, and the system 102 may manage variance in accordance with those thresholds. In some examples, the user system 104 of FIG. 1 may be used to approve and / or decline and / or change coefficient adjustments proposed by the quoting system 106. Coefficient adjustments may be declined and / or changed, for example, when an impact on consumer sales may be greater than a threshold amount.

[0072] During operation, quoting systems described herein may be used to generate resource calculations in a manner that manages variance. Consider an example of an instance (e.g., a transaction) occurring at seller system 108. The checkout process 134 may identify an item that a consumer has indicated to purchase (e.g., by placing the item in a virtual cart). The checkout process 134 may request a resource calculation (e.g., a quote) from the quoting system 106. For example, the checkout process 134 may, responsive to an item being put in a cart and / or otherwise indicated for purchase, send an API call to the quoting APIs 122 to request a quote. The API call may include an indication of the item, jurisdiction of the transaction, and / or jurisdiction of the seller. In some examples, the quoting service 116 may obtain information about the item and / or one or more jurisdictions from the data 118. Generally, examples described herein may advantageously generate resource calculations fortax and / or duty amounts applicable to cross-border transactions. Accordingly, one or more online storefront systems, such as seller system 108, may call the quoting APIs 122 in real time at checkout when a consumer wants to buy a product internationally. While a single seller system 108 is shown in FIG. 1, it is to be understood that many seller systems may be in communication with quoting system 106. The request from the seller system 108 may be a request to generate a resource calculation for international importation fees. While examples are described with respect to a single item, it is to be understood that the request can pertain to multiple items (e.g., each item in a shopping basket). Resource calculations for multiple items may be requested in a single request to quoting APIs 122 in some examples. In some examples, multiple requests may be used, with fewer than all requested items present in a single request.

[0073] The quoting APIs 122 may provide information to the quoting service 116 to provide a quote. The quoting service 116 may generate a resource calculation for the transaction, which may be a resource calculation associated with the item and a jurisdiction (e.g., the jurisdiction of the consumer). In order to perform the resource calculation, such as a calculation of tax and / or duty, the quoting service 116 may classify the item. For example, the quoting service 116 may generate an estimated HS code for the item. The quoting service 116 may generate the estimated HS code based on information regarding the item received from seller system 108 and / or stored in data 118, for example. In some examples, an artificial intelligence and / or machine learning model may be used to generate the estimated HS code. The quoting service 116 may generate the resource calculation based on the estimated HS code. For example, the quoting service 116 may access one or more rules databases (not separately depicted in FIG. 1) which may indicate an amount of duty and / or tax to be applied based on the HS code and jurisdiction. The resource calculation (e.g., an amount of duty and / or tax) may be provided by the quoting system 106 to the seller system 108. For example, the quoting service 116 may provide the resource calculation to the quoting APIs 122 and the APIs may return the resource calculation to the seller system 108. The seller system 108 may display the resource calculation, e.g., using checkout process 134, and may bill a consumer for the amount of resources calculated.

[0074] The resource calculations may be persisted by the quoting APIs 122. For example, the resource calculation(s) responsive to a request may be stored in a data file that may be provided to datastore 126. The datastore 126 may utilize ETLs to normalize and store the values for each calculated resource (e.g., duty, tax, other), and for each item associated with the request (e.g., each item in a customer basket). In some examples, the quoting APIs 122 may generate a unique key for each generated resource calculation. The unique key may beused as a primary key by the datastore 126 to reconcile actual resource calculations and / or resimulated resource calculations with the initial resource calculations made prior to the consummation of the transaction, where those resource calculations may have a matching key.

[0075] Following completion of the transaction (e.g., after a consumer has been charged an amount based on the item price and the resource calculation using the estimated HS code), the item may again be classified. The second classification may be more accurate in some examples, because the second classification, occurring after the transaction, may have time to be reviewed and prepared by an expert system and / or person. The second classification, such as a second HS code, may be received by the quoting system 106. For example, a posttransaction HS code may be provided by data 118, such as data received and / or provided from an expert system. This HS code may be retrieved by the quoting APIs 122 in some examples. The quoting service 116 may again generate a resource calculation for the transaction, this time using the post-transaction classification (e.g., the post-transaction HS code). The resource calculation may be associated with the item and the jurisdiction (e.g., jurisdiction of the consumer). This second resource calculation may be provided by the quoting service 116 to, for example, estimate data 124. The second resource calculation may be provided with a key which matches the key generated for the resource calculation made prior to the consummation of the transaction. The first resource calculation (e.g., before the consummation of the transaction) may also be provided to estimate data 124. Accordingly, the first and second resource calculations may be associated based on having matching key values in datastore 126.

[0076] The quoting system 106 (e.g., using quoting service 116 and / or datastore 126) may calculate a simulated variance between the first resource calculation and the second resource calculation. The variance may be stored in variance data storage 128. The quoting system 106 may generate a coefficient for use in generating a subsequent resource calculation. The coefficient may be intended to reduce the simulated variance. For example, if the variance was determined to be 5% of the estimated duty' and / or tax, the coefficient may be 0.95. In some examples, the coefficients may be saved and stored, for example, in data 118. In some examples, a cross-border quoting configuration rule table may be used to store the coefficients. Other data structures may be used in other examples. In this manner, when generating a resource calculation, the quoting service 116 may utilize the coefficient, such as by multiplying the coefficient by an initial resource calculation to provide a final resource calculation to the seller system 108. The coefficient may be used by the quoting service 116 for subsequent transactions involving the item and the jurisdiction.

[0077] In some examples, the coefficient generated by the coefficient calculator 130 may be automatically incorporated into resource calculations made by the quoting service 116. In other examples, the coefficient may be further evaluated before it is used to influence subsequent resource calculations. In some examples, the quoting system 106 (e.g., the coefficient calculator 130) may adjust the calculated coefficient based on an estimated impact of the coefficient on a number of subsequent resource calculations. For example, an estimated impact of the coefficient may be calculated. The estimated impact may be based on anticipated sales volume of the item in the jurisdiction associated with the coefficient. If greater than a threshold volume of sales is expected, the coefficient may be provided to user system 104 for further review, and / or may be revised lower to reduce an impact of the change on the sales volume. In some examples, if the coefficient is greater and / or less than a threshold, the coefficient may be reduced and / or increased to the threshold coefficient value. For example, the coefficient calculator 130 may modify the coefficient value. In this manner, large short-term effects to transactions may be reduced and / or avoided.

[0078] Accordingly, in some examples, systems described herein may calculate a sensitivity7score. The sensitivity score may be associated with a particular combination of item and jurisdiction. The sensitivity score may be calculated by the quoting system 106, such as by the quoting service 116 and / or coefficient calculator 130. The sensitivity score may be based on a volume of expected transactions involving the item and the jurisdiction. The expected volume may be identified by the quoting system 106 based on historical volume of sales stored in data 118 and / or provided by computing system 136. The coefficient calculator 130 and / or quoting service 116 may modify a coefficient based on the sensitivity score. In some examples, when the sensitivity7score meets or exceeds a threshold, the quoting system 106 may provide the coefficient to user system 104 for approval and / or modification.

[0079] When the quoting system 106 provides the coefficient to user system 104 for approval and / or modification, the quoting system 106 may notify one or more users. For example, the quoting system may provide a notification to the user system 104. For example, a message may be displayed on a user interface of user system 104 and / or an email, text, or other message provided to the user system 104. The notification may indicate that a sensitivity score for a coefficient adjustment exceeds a threshold. A user may provide a response to the notification. For example, a user may utilize computer system 112 to provide a response back to quoting system 106. The response may indicate approval of the coefficient adjustment. Responsive to the approval, the quoting system 106 may implement the coefficient adjustment and begin utilizing the coefficient in the quoting service 116. For example, the quoting system 106 may utilize the coefficient to calculate resource obligationsrelating to subsequent transactions involving an item. The response may indicate refusal of the coefficient adjustment. Responsive to refusal, the quoting system 106 may not utilize the coefficient adjustment and may not use the proposed coefficient in quoting service 116. The response may indicate a changed coefficient adjustment. Responsive to a changed adjustment, the quoting system 106 may utilize the changed coefficient adjustment in the quoting service 116. In this manner, some coefficients may be automatically implemented by the quoting service 116 to manage variance. However, some coefficients associated with a sensitivity score over a threshold may utilize a notification of another system (e.g., user system 104) prior to implementation of the coefficient. This may allow systems described herein to tradeoff between the speed and scalability of fully automated coefficient updates for variance management and addressing risk of sales loss or other adverse effects from a more extreme coefficient update.

[0080] In some examples, accordingly, the quoting system 106 may manage simulated variance. In some examples, the quoting system 106 may additionally or instead manage actual variance. An actual resource calculation for the transaction may be received associated with the item and the jurisdiction. The actual resource calculation may be received, for example, from computing system 136 of FIG. 1 and / or carrier data 138. In some examples, it may take time for this resource calculation to be received. The resource calculation may be reflected, for example, on an invoice provided from a carrier and / or importer to a seller. In some examples, it may take 60-90 days for such an invoice to be received and transmitted to the quoting system 106. Shorter or longer periods may occur in some examples. Using this actual resource calculation, the quoting system 106 may calculate actual variance (e.g., using datastore 126 and / or coefficient calculator 130 and / or computer system 114). The actual variance may be stored in variance data storage 128. The coefficient calculator 130 may calculate a coefficient for use by the quoting service 116 that is based on the actual variance. In some examples, the coefficient calculator 130 may calculate a coefficient for use by the quoting service 116 that is based on both the actual and the simulated variance.

[0081] FIG. 2 is a schematic illustration of a system arranged in accordance with examples described herein.

[0082] As can be seen in FIG. 2, a sample computer system 202 according to embodiments is shown. The computer system 202 has one or more processors 204 and a memory’ 206. The memory 206 stores programs 208 and data 210. An element of the data 210 is a resource 212 that is produced as described herein (e.g., a resource calculation). The processors 204 and the memory’ 206 of the computer system 202 thus implement a service engine 214.

[0083] In some examples, all or portions of the system of FIG. 2 may be used to implement and / or may be implemented by components shown in FIG. 1. For example, computer system 202 may be used to implement quoting system 106 of FIG. 1. The service engine 214 may be used to implement the quoting service 116 of FIG. 1, for example.

[0084] The computer system 202 can be located in “the cloud.” In fact, the computer system 202 may optionally be implemented as part of an Online Software Platform (OSP) 216. The quoting system 106 and / or computer system 114 of FIG. 1 may be used to implement and / or may be implemented by the computer system 202 and / or OSP 216 in some examples. The computer system 202 can be configured to perform one or more predefined services, for example, via operations of the service engine 214. Such services can be searches, determinations, computations, verifications, notifications, the transmission of specialized information, including data that effectuates payments, the generation and transmission of documents, the online accessing of other systems to effect registrations, and so on, including what is described in this document. Producing the resource 212 (e.g., generating one or more resource calculations) can be part of one of these services. Such services can be provided in the form of Software as a Service (SaaS). As such, the OSP 216 can be an online service provider.

[0085] A computer system 218 can be part of a secondary’ entity 220. The secondary' entity 220 can be an organization. In some examples, the computer system 218 may be used to implement and / or may be implemented by the carrier system 110 of FIG. 1.

[0086] A user 232 may be standalone. The user 232 may use a computer system 228 that has a screen 230, on which user interfaces (UIs) may be shown. The seller system 108 of FIG. 1 may be used to implement and / or may be implemented by the computer system 228 in some examples. In embodiments, the user 232 and the computer system 228 are considered part of a primary entity 236, which could be an organization, an institution, and so on. In such instances, the user 232 can be an agent of the primary' entity 236, and even within a physical site of the primary entity 236. although that is not necessary’. The primary entity 236 may be an operator of the OSP 216 in some examples. The primary entity 236 may be a seller in some examples. In embodiments, the computer system 228 or other device of the user 232 can be client devices for the computer system 202. The user 232 or the primary’ entity 236 can be clients for the OSP 216. For instance, the user 232 may log into the computer system 202 by using credentials, such as a username, a password, a token, and so on.

[0087] While user 232 is shown in FIG. 2 with respect to computer system 228 and primary' entity 236, other users of other systems may also be present. For example, one or more usersmay interact with OSP 216 and / or computer system 202 using one or more computing systems. For example, the user system 104 of FIG. 1 may be in communication with OSP 216 and / or computer system 202 in some examples.

[0088] The computer system 228 may access the computer system 218 via a communications network 226, such as the internet. In particular, the entities and associated systems of FIG. 2 may communicate via physical and logical channels of the communications network 226. Accordingly, from certain perspectives, the secondary7entity 220 is in the cloud.

[0089] The computer system 228 may access the computer system 202 via a communications network 226, such as the internet. Accordingly, from certain perspectives, the OSP 216 is in the cloud.

[0090] In some instances, the computer system 202 may access the computer system 218 on behalf of the primary7entity 236.

[0091] Accessing, downloading and / or uploading, and so on may be permitted among these computer systems. Such can be performed, for instance, with manually uploading files, like spreadsheet files, etc. Such can also be performed automatically as shown in the example of FIG. 2, with systems exchanging requests and responses.

[0092] Moreover, in some embodiments, data from the computer system 228 and / or from the computer system 202 may be stored in an Online Processing Facility (OPF) 234 that can run software applications, perform operations, and so on. In such embodiments, requests and responses may be exchanged with the OPF 234, downloading or uploading may involve the OPF 234, and so on. In such embodiments, the computer system 228 and any devices of the OPF 234 can be considered to be remote devices, at least from the perspective of the computer system 202.

[0093] In embodiments, the user 232 and / or the primary entity 236 have instances of relationships with secondary7entities. Only one such secondary entity 238 is shown. The secondary7entity 238 can be an organization, a person, and so on. In some embodiments, the secondary entity 238 has a device 222, which can be an electronic device such as a cellphone, tablet, laptop, computer system, and so on. The device 222 may have a screen 224. In this example, the secondary7entity 220 has a relationship instance 242 with the secondary7entity 238. In fact, the secondary7entity 238 may have used a device such as the device 222 to create the relationship instance 242. The secondary entity 220, the primary entity 236, and / or the secondary entity 238 may be referred to as simply entities.

[0094] In some instances, the user 232 and / or the primary7entity 236 obtain data about one or more secondary entities, for example, as necessary or advantageous for conducting therelationship instances with them. The obtained data can be about attributes of the entities, or of the relationship instances. In some instances, the secondary entity 220 may obtain data about primary entity 236 and / or one or more secondary entities.

[0095] In embodiments, the computer system 202 receives one or more datasets. A sample received dataset 240 is shown. The dataset 240 may be received by the computer system 202 in a number of ways. In some embodiments, one or more requests may be received by the computer system 202 via a network. The received one or more requests can carry' payloads. In such embodiments, the one or more payloads may be parsed by the computer system 202 to extract the dataset.

[0096] In embodiments, the dataset 240 has parameters that can also be called dataset parameters. At least some of the dataset parameters have respective values that can also be called dataset values. The dataset values can be numerical, alphanumeric. Boolean, and so on, as needed for what the parameters characterize. For example, the value of an identity parameter ID may indicate an identity of the dataset 240, so as to differentiate it from other such datasets. At least one of the dataset values may characterize an attribute of a certain one of the entities such as primary entity 236, secondary entity 220, secondary entity 238, and / or as indicated by correspondence arrows 244. For instance, a parameter DI may have the value of a name of the certain entity, a parameter D2 may have a value of relevant data of the entity, and so on. Plus, an optional dataset parameter Bl may have a numerical base value. The base value Bl can be for an aspect of the dataset, and so on. The aspect of the dataset may be the aspect of a value that characterizes the attribute, an aspect of the reason that the dataset was created in the first place, an aspect of the relationship instance 242, and so on. The dataset 240 may further have additional dataset parameters, as indicated by the horizontal dot- dot-dot in the right side of the dataset 240. In this document, the dot-dot-dot, whether horizontal or vertical, means '‘potentially more of’ what it is shown together with. In embodiments, the dataset values characterize attributes of both the primary entity 236 and the secondary' entity 238, but that is not required.

[0097] In embodiments, the computer system 202 may identify and / or calculate a resource based on the dataset. In this example, the secondary entity 220 may provide certain resource data in the dataset. The primary' entity' 236 may provide certain object and / or resource data in the dataset. The secondary entity 238 may provide data for the dataset, such as jurisdiction. In some examples, data associated with secondary entity 238 may be provided by primary entity 236 to the dataset.

[0098] In embodiments, the computer system 202 produces a resource calculation based on the dataset 240, such as the resource 212. The produced resource can be a document, a determination, a file, or a computational result, etc., made, created or prepared for the user 232, and / or the primary' entity 236, and / or the secondary entity' 238, and / or the secondary' entity 220, etc. As such, in some embodiments, the resource is produced by processing and / or a computation. In some embodiments, therefore, the resource is produced on the basis of a classification of an item identified by primary' entity 236.

[0099] As seen above, the computer system 228, the computer system 202, and possibly also the OPF 234 may exchange requests and responses. Such can be implemented with a number of different architectures. Sample architectures are described herein yvith reference to the computer systems 228 and 202.

[0100] FIG. 3 is a flowchart illustrating an example method for measuring variance arranged in accordance with examples described herein. FIG. 3 may demonstrate an example order of operations for measuring variance between an initial resource calculation performed at the time of a transaction (e.g., prior to consummation of the transaction) and a subsequent resource calculation performed after the transaction (e.g., when a more accurate item classification may be made).

[0101] According to some examples, the method includes starting at block 304. The method includes block 310, which recites “receive call to quoting APIs for transaction.” Block 310 may be followed by block 312, yvhich recites “generate resource calculation using classification.” Block 312 may be followed by block 314, which recites “save estimates.” Block 312 may also be followed by block 316, which recites “receive second classification.” Block 312 and block 316 may be followed by block 318. which recites “re-generate resource allocation.” Block 318 may' be followed by block 320, which recites “save additional estimates.” Block 320 may be folloyved by block 322, yvhich recites “ayvait carrier data.” Block 322 may be followed by decision block 324 which recites “does invoice data exist for transaction?” If yes, block 324 may be followed by block 326, which recites “save actuals.” If not, block 324 may be followed by block 328 which recites “check time.” Block 328 may be folloyved by7decision block 332, which asks “over threshold?” If not, block 322 may folloyv block 332. If yes, block 332 may be followed by block 330, yvhich recites “assign actuals.” Block 330 may be folloyved by block 326, yvhich recites “save actuals.” Resource calculations (e.g.. estimates) generated during the method of FIG. 3 may be stored in variance data storage 334.

[0102] The method of FIG. 3 may be implemented in some examples using quoting systems described herein. For example, the quoting system 106 may be used to perform the method of FIG. 3. For example, the computer system 114 may include memory encoded with executable instructions which, when executed by one or more processors of the computer system 114, cause the quoting system 106 to perform the operations shown and described with reference to FIG. 3. The variance data storage 128 of FIG. 1 may be used to implement and / or may be implemented by the variance data storage 334 of FIG. 3. The method of FIG. 3 may be implemented in some examples using the computer system 202 of FIG. 2. For example, the memory 206 may be encoded with executable instructions which when executed by the processor 204, cause the computer system 202 and / or the OSP 216 to perform the operations described in FIG. 3.

[0103] The operations of FIG. 3 are exemplary. In other examples, additional, fewer, and / or different operations may be used. The operations may be arranged in other orders in other examples.

[0104] The flowchart of FIG. 3 begins with block 304. which recites “start.” The method may be initiated, for example, during an instance of a relationship between entities described herein, such as between a seller and a consumer. For example, a consumer may have selected one or more items and initiated a transaction for the items (e.g., by placing the items in a cart). For example, the primary entity 236 and secondary entity 238 of FIG. 2 may initiate a relationship or instance (e.g.. a transaction). In some examples, a consumer may initiate an instance with the seller system 108 of FIG. 1.

[0105] Block 310 recites “receive call to quoting APIs for transaction.” In some examples, a communication may be provided to a quoting system indicative of a transaction. The quoting APIs 122 of FIG. 1 may be called, for example, in block 310. While API communication is described, other communication protocols may be used in other examples. In some examples, in block 310, a duty' and tax estimation API (e.g., quoting APIs 122) may be called, and the call may be made responsive to a cross-border transaction. A cross-border transaction may refer to a transaction in which customs or other duty may be applied, and / or a transaction where an item may be classified using an HS code. The call in block 310 may come from an online store checkout (e.g., seller system 108 and / or checkout process 134 of FIG. 1). Note that there may not be any HS code available at the time of block 310 to generate a resource calculation (e.g., tax and / or duty estimate). The call made in block 310 may identify one or more items associated with a transaction, and one or more jurisdictions associated with the transaction.

[0106] Block 312 recites “generate resource calculation using classification ’ A classification of one or more items involved in the transaction may be made, for example, by quoting system 106 of FIG. 1. The classification may be made, for example, using artificial intelligence and / or machine learning techniques. The classification may be made based on information about the item(s), such as item name, description, image, video, metadata, and / or other information which may be provided by seller system 108 and / or accessed in data 118 of FIG. 1 in some examples. The classification may result in one or more HS codes being associated with the item and / or returned by the quoting system. The resource calculation in block 312 is generally timely made in order to be presented to a consumer and charged to the consumer at a consummation of the transaction. The resource calculation may be made based on the classification (e.g., the HS code). For example, the quoting system 106 of FIG. 1 may look up, calculate, or otherwise access an amount of tax and / or duty7associated with the HS code. Accordingly, an online store may collect from a consumer an estimated amount of tax and / or duty generated in block 312. After being presented with the resource calculation, a consumer may complete the transaction, and may be charged for the estimated tax and / or duty.

[0107] Block 314 recites “save estimates.” The resource calculation made in block 312 may be saved, for example, to variance data storage 334. In some examples, estimated values for duties and / or taxes are parsed and saved in block 314.

[0108] Block 316 recites “receive second classification.” Block 316 may occur after a transaction is complete. For example, following completion of a transaction, the seller system 108 of FIG. 1 may again call quoting APIs 122 to request a post-transaction classification. Expert systems may in some examples be used to generate a post-transaction classification, such as an HS code. For example, the quoting system 106 may, responsive to a request for a post-transaction classification at quoting APIs 122, request an estimate from an expert system or other computing system. In some examples, human review may be provided to generate a post-transaction HS code. More time and / or information may be available at block 316 to generate an HS code than had been available at block 312 to generate an initial HS code. Accordingly, the classification (e.g.. HS code) generated at block 316 may in some examples be more accurate. In some examples, it may take 24 hours to obtain a classification in block 316, although other times may be used including, but not limited to, 12 hours, 2 days, or 4 days. In some examples, the second classification (e.g., HS code) may be provided to the seller system 108 of FIG. 1 for use in preparing customs documentation (e.g., commercial invoices and / or manifests). The seller system 108 may insert the HS code received in block 316 into one or more transmissions to a customs authority and / or importer / exporter.

[0109] Block 318 recites ”re-generate resource calculation.” The quoting system 106 may again generate a resource calculation, this time using the second classification. Recall the second classification may be more accurate. These estimates (e.g., tax and / or duty) may be saved in block 320, which recites “save additional estimates.” For example, the estimates may be saved to variance data storage 334 of FIG. 3. The second classification (e.g., HS code) may also be saved, for example, in variance data storage 334 of FIG. 3, variance data storage 128 of FIG. 1, and / or data 118 of FIG. 1. In this manner, initial tax and / or duty estimates for a transaction may be stored in variance data storage 334, and updated tax and / or duty estimates generated post-transaction may also be stored in variance data storage 334. Other memory and / or storage may be used in other examples. The variance data storage 334 may be implemented using a database or other data structure, and may be stored in generally any storage media, such as one or more memories, hard disk drives, solid state drives, and / or cloud storage.

[0110] Block 322 recites “await carrier data.” In some examples, actual resource calculations may be obtained and used to calculate and / or manage variance as described herein. Carriers (e.g., shippers and / or importers) may ultimately assign an HS code to one or more items in a transaction, assess an actual amount of tax and / or duty, and charge the seller and / or the consumer the tax and / or duty amount. It may be advantageous to obtain those actual resource calculations to update quoting techniques described herein to manage variance. The amount of import fees collected at checkout versus carrier invoice fees over time can lead to large over- or underestimates, creating either conversion issues (in examples with overestimates) or financial losses (in examples with underestimates) in examples where the end buyer is guaranteed the costs at checkout (e.g., delivered duty paid (DDP) service). For example, if the carrier ultimately calculates an actual tax and / or duty that is greater than the amount charged the buyer during the transaction, the seller may be responsible for incurring the difference. These unexpected additional amounts may reduce the economic viability of the transaction. If the carrier ultimately calculated an actual tax and / or duty that is less than the amount charged the buyer during the transaction, the seller may have missed an opportunity to present an overall lesser transaction price to a buyer, which would have potentially allowed the seller to close more transactions. To allow for quoting systems described herein to measure the variance between checkout, post-checkout, and invoiced resource calculations, quoting systems may receive and store the resource calculations at each of these stages, for example, in variance data storage 334. For example, a seller may send customs invoice data to one or more quoting systems described herein, such as quoting system 106 of FIG. 1. It may take time (e.g., 60 days) to receive such an invoice. Accordingly, inblock 324, the quoting system 106 may evaluate whether invoice data exists for a transaction, such as by checking whether invoice data has been received. The system may check for invoice data by reviewing stored invoice data for a key or other unique identifier(s) associated with the transaction.

[0111] If carrier invoice data for the transaction had been received, in block 326, the system (e.g., quoting system 106 of FIG. 1) may save the actual resource calculation (e.g., actual tax and / or duty ). The actuals may be stored, for example, in variance data storage 334. If invoice data had not been received, block 328 recites “check time.” If less than a threshold time had passed, the system may continue to await the carrier data, back in block 322. If over a threshold time had passed, the system may assign actuals in block 330. Examples of threshold times include 90 days, 120 days, and / or 180 days. For example, in block 330, it may be assumed that after the threshold time, no carrier invoice may be received, and a resource calculation may be assigned to the transaction. For example, a $0 tax and duty amount may be associated with the transaction, because it may be that no such tax and / or duty was owing. Generally, carriers do not send invoices for $0 when a parcel’s contents are duty and tax free. Entering a 0 value in variance data storage systems described herein may be advantageous to allow systems to reconcile the initial resource calculation, post-transaction resource calculation, and actual resource calculation by a third party (e g., a carrier). In some examples, however, records with no invoice data may be discarded - e.g., deleted and / or subject to an “end of life’' procedure, and the transaction may be recorded as an overestimate. For example, if a carrier does not send an invoice after the agreed upon billing terms (e.g., 90 days no invoice received means you are not ever getting an invoice), systems described herein may not discard any records, but the system may now reconcile a value of $0 with whatever the estimates were. If the estimates were $0 and no invoice is received, the system may be correct (e.g., no financial impact). If the estimates were non-zero and no invoice was received, the system may provide a $0 actual record so the system may record the over-estimate. Without this process, the system may have estimates that never make it into any financial reporting because they remain waiting to be reconciled and never show up in the system as overestimates.

[0112] In this manner, systems described herein may store a resource calculation made at a time of a transaction (e.g., before transaction completion), a post-trans action resource calculation, and / or an actual resource calculation. The variance between these calculations may be managed using systems described herein. By managing the variance, subsequent resource calculations made by systems described herein may be more accurate (e.g., may have less variance to post-transaction resource calculations and / or actual resource calculations).Utilization of coefficients described herein to adjust resource calculations may result in more accurate resource calculations. Note that these methods may be utilized without requiring a merchant to themselves classify all offered items across all jurisdictions in which the merchant may be selling.

[0113] FIG. 4 is a schematic illustration of variance data and a process for coefficient generation arranged in accordance with examples described herein. FIG. 4 depicts variance data storage 402. The variance data storage 402 may include an actual invoice table 404, an estimate table 406, a simulated actuals table 408, an actual variance table 410, and a simulated variance table 412. FIG. 4 depicts a process for coefficient generation. Block 414 recites “generate variance dashboards.” Block 416 recites “calculate coefficient(s) based on actual variance.” Block 418 recites “calculate coefficient(s) based on simulated variance.” Block 420 recites “set customer variance target.” Block 422 recites “calculate conversion sensitivityscore.”

[0114] Quoting systems and / or user systems described herein may be used to store the data and perform the operations shown in FIG. 4. For example, the quoting system 106 and / or user system 104 of FIG. 1 may be used to store the data and perform the operations shown in FIG. 4. In some examples, the computer system 202 may be used to store the data and perform the operations shown in FIG. 4.

[0115] The data and operations shown in FIG. 4 are exemplary. Additional, less, and / or different data may be stored in some examples. Additional, fewer, and / or different operations may be performed in some examples.

[0116] FIG. 4 illustrates a schematic example of data that may be stored in variance data storage described herein. For example, the variance data storage 402 may be used to implement and / or may be implemented by the variance data storage 128 of FIG. 1 and / or the variance data storage 334 of FIG. 3.

[0117] In the example of FIG. 4, the variance data storage 402 may' include actual invoice table 404, estimate table 406, simulated actuals table 408, actual variance table 410, and simulated variance table 412. While tables are described and shown, it is to be understood that generally any data structure may be used. The actual invoice table 404 may include data based on information obtained from carrier invoice(s). As shown in FIG. 4, the actual invoice table 404 may include pre-coefficient duties, post-coefficient duties (if applicable), precoefficient taxes, post-coefficient taxes (if applicable), pre-coefficient other, post-coefficient other (if applicable), carrier HS code, and order value (e.g., including one or more item prices). The pre-coefficient duties may generally refer to a duty amount calculated withoutusing any coefficients as described herein. Post-coefficient duties may generally refer to a duty amount calculated using coefficients described herein (e.g., applying one or more coefficients to the pre-coefficient duty). The pre-coefficient taxes may generally refer to a tax amount calculated without using any coefficients as described herein. Post-coefficient taxes may generally refer to a tax amount calculated using coefficients described herein (e.g., applying one or more coefficients to the pre-coefficient taxes). The pre-coefficient other may generally refer to other amounts (e.g., fees, service amounts) calculated without using any coefficients as described herein. Post-coefficient other may generally refer to a duty amount calculated using coefficients described herein (e.g.. applying one or more coefficients to the pre-coefficient other). The amounts shown in the actual invoice table 404 are generated using the carrier HS code, which is also stored in actual invoice table 404. The carrier HS code may refer to an HS code assigned to a transaction by a carrier. The tax and duty' amounts in actual invoice table 404 may be those shown on a carrier invoice in some examples. While tax amounts and duty amounts are shown in FIG. 4, other resources may be calculated in other examples.

[0118] In the example of FIG. 4, the variance data storage 402 may include estimate table 406. The estimate table 406 may include pre-coefficient duties, post-coefficient duties (if applicable), pre-coefficient taxes, post-coefficient taxes (if applicable), pre-coefficient other, post-coefficient other (if applicable), estimator HS code, and order value. The amounts shown in the estimate table 406 are generated using the estimator HS code, which is also stored in estimate table 406. The estimator HS code may refer to an HS code generated during a transaction, e.g., using an AI / ML system. The amounts charged to a consumer may be those shown in estimate table 406.

[0119] In the example of FIG. 4, the variance data storage 402 may include simulated actuals table 408. The simulated actuals table 408 may include pre-coefficient duties, postcoefficient duties (if applicable), pre-coefficient taxes, post-coefficient taxes (if applicable), pre-coefficient other, post-coefficient other (if applicable), actual product HS code, and order value. The amounts shown in the estimate table 406 are generated using the actual product HS code, which is also stored in estimate table 406. The actual product HS code may refer to an HS code assigned after the transaction by, e g., an expert system.

[0120] In the example of FIG. 4, one record is shown for each table, with the record having a unique identifier - "PK represents that identifier in the example of FIG. 4. The unique identifier may be, for example, an alphanumeric string which may identify the data associated with a transaction and / or with an item. The unique identifier may be a key. In some examples,the quoting system 106 may generate the identifier and / or may associate the identifier with a particular transaction. Take an example of a transaction having an identifier “60795364.” A record having that identifier may appear in each of actual invoice table 404, estimate table 406, and simulated actuals table 408. The identifier may facilitate association (e.g., matching) of records to allow for variance calculations described herein.

[0121] The variance data storage 402 may include an actual variance table 410. The actual variance table 410 may store variance (e.g., difference) between values in actual invoice table 404 and estimate table 406. The variance (e.g.. values in the actual variance table 410) may be calculated by quoting systems described herein, such as quoting system 106 of FIG. 1 (e.g., using computer system 112 and / or coefficient calculator 130).

[0122] The variance data storage 402 may include simulated variance table 412. A simulated variance table 412 may store variance (e.g., difference) between values in simulated actuals table 408 and estimate table 406. The variance (e.g., values in the simulated variance table 412) may be calculated by quoting systems described herein, such as quoting system 106 of FIG. 1 (e.g., using computer system 112 and / or coefficient calculator 130).

[0123] The tables and other data stored in variance data storage in examples described herein may be used to perform a variety of operations. In the example of FIG. 4, in block 414, one or more variance dashboards may be generated. For example, the quoting system 106 of FIG. 1 may generate a variance dashboard and may display the variance dashboard to a user using a user interface of user system 104 and / or quoting system 106. The variance dashboard may display actual and / or simulated variance calculations for particular jurisdictions, sellers, items, or across other factors. This may allow a user to visually assess variances that may reflect over- or under-estimates of tax and / or duty, or HS code estimation that may be underperforming.

[0124] In block 416, one or more coefficient(s) may be calculated based on actual variance. As described herein, for example, the quoting system 106 of FIG. 1 may calculate one or more coefficients for use in generating a resource calculation (e g., a duty and / or tax amount). The coefficients calculated in block 416 may be based, for example, on the data in actual variance table 410.

[0125] In block 418, one or more coefficient(s) may be calculated based on simulated variance. As described herein, for example, the quoting system 106 of FIG. 1 may calculate one or more coefficients for use in generating a resource calculation (e.g., a duty and / or tax amount). The coefficients calculated in block 418 may be based, for example, on the data in simulated variance table 412.

[0126] The coefficients calculated in block 416 and block 418 may in some examples be calculated on a per-jurisdiction basis. For example, selected data from actual invoice table 404 and / or simulated variance table 412 may include records from a particular jurisdiction. Records from that particular jurisdiction may be used to generate coefficient(s) for that jurisdiction in block 416 and block 418. Subsequent resource calculations for that jurisdiction may use the coefficients.

[0127] In some examples, a user may set a variance target in block 420. For example, a user may input a selected variance amount. The quoting system 106 of FIG. 1 may receive the selected variance amount, and may calculate coefficients to result in a variance equal to, or closer to, the selected variance amount. For example, a user may indicate a variance amount associated with a particular risk level (e.g., 1% variance associated with low risk, 10% variance associated with high risk). Other risk levels and variance amounts may be used in some examples.

[0128] Accordingly, the quoting system may utilize the selected variance target in generating one or more coefficients for use in a resource calculation to bring expected variance in a system to, or closer to, the target variance.

[0129] Having calculated coefficients intended to drive expected variance down and / or toward or to a target level, examples of systems described herein may determine whether to implement the coefficients. Accordingly, quoting systems described herein may, in block 422, calculate a conversion sensitivity score. The conversion sensitivity score may provide an estimate of an impact use of the coefficient may have on transactions. Coefficients having greater than a threshold impact may be modified and / or transmitted for further review. Coefficients having less than a threshold impact may be automatically utilized by quoting systems described herein in subsequent resource calculations.

[0130] FIG. 5 is a schematic illustration of a user interface (UI) displaying a variance dashboard in accordance with examples described herein. The UI 504 is shown on a screen 502. The UI 504 may display a variance dashboard. The UI 504 may include button 506 for “select time range,” button 508 for “select jurisdiction(s),” and button 510 for “set threshold(s).”

[0131] The user system 104 of FIG. 1 may be used to display UI 504 in some examples, and the data for the variance dashboard may be obtained from quoting system 106 in some examples. The interface shown in FIG. 5 is exemplary. Additional, less, and / or different information may be displayed and / or other user interface elements may be present in other examples.

[0132] The variance dashboard of FIG. 5 is shown displaying monthly baseline variances for the months January, February, March, and April. The simulated variance is shown as a 4% overestimate in January', 5% overestimate in February', 10% overestimate in March, and 15% overestimate in April. The simulated variance metric reported in the variance dashboard may be a combined metric for all simulated variance for an entity, such as a seller. In some examples, the simulated variance metric report may be a combined metric specific to entity (e.g., seller), item, and / or jurisdiction. In the example of FIG. 5, the simulated variance metric may be an average of all simulated variance data for a seller. For example, the quoting system 106 of FIG. 1 may average all calculated simulated variance amounts for a particular seller, such as by averaging records in simulated variance table 412 of FIG. 4.

[0133] The actual variance (e.g., invoiced variance) is shown as a 10% overestimate in January’ and 11% overestimate in February. For March and April, the variance dashboard indicates that the system is waiting for invoice data to calculate actual variance. Accordingly, an indication of awaiting invoice data (e.g., “waiting for invoices”) is displayed. The actual variance metric reported in the variance dashboard may be a combined metric for all actual variance for an entity, such as a seller. In some examples, the actual variance metric report may be a combined metric specific to entity (e.g.. seller), item, and / or jurisdiction. In the example of FIG. 5, the actual variance metric may be an average of all actual variance data for a seller. For example, the quoting system 106 of FIG. 1 may average all calculated actual variance amounts for a particular seller, such as by averaging records in actual variance table 410 of FIG. 4.

[0134] The variance dashboard of FIG. 5 reports a difference in simulated versus invoiced baseline. For example, the quoting system 106 of FIG. 1 may subtract values in actual variance table 410 from those in simulated variance table 412 in some examples. The simulated versus actual baseline for January was a -6% difference, for February a -6% difference, and the dashboard displays an insufficient data notification (e.g., “Missing Data”) for March and April. The insufficient data notification may be due to the system still awaiting invoice data. The insufficient data and / or awaiting invoice notification may be presented if any invoices are still awaited in some examples, or if over a threshold percent of records are awaiting invoices in some examples.

[0135] The variance dashboard of FIG. 5 further may display user alerts. In the example of FIG. 5, early warning alerts are described for each month, as are the disposition of the warnings. The quoting system 106 of FIG. 1 , for example, may generate one or more warnings based on variance data, such as variance data in variance data storage 128. January' had nowarnings, and so the disposition also reflects no warnings provided. February had no warnings, and additionally displayed a notification that the time period’s variance (e.g., month) was the same as the previous month. The disposition of February alerts was also no warnings provided. In March, the warning summary provided by the variance dashboard displayed an indication that a warning was provided, and a cause of the warning. In March, the dashboard displayed “Yes - large increase in simulated %.” Note that an alert may be generated, such as by quoting system 106 of FIG. 1, when the variance in a time period increases by greater than a threshold amount over a previous time period. An example threshold amount may be 3%, or 5% in some examples. Other thresholds may also be used. In April, the dashboard also displayed “Yes - large increase in simulated %.” In both March and April, the variance dashboard displayed an indication that an alert had been made to a user (e.g., an internal user). The quoting system 106 may alert a user, for example, using a transmission such as an email, text, voicemail, or other notification.

[0136] In some examples, an alert may be an early warning alert. The early warning alert may use changes in the simulated variance (which may lead actual variance by a period of time, such as 60 days) as a way to alert the internal user that something has changed in the average variance between the time of transaction and a later time. This could be caused by changes in the content that drives the quoting system such as duty rates or changes to other regulations impacting estimates. It could also be caused by changes to the types of goods being sold in the online store, which may have greater or lower average fees. This early warning signal can be used to trigger investigations into the root cause of estimates deviating from their established baseline, and whether or not additional coefficients may be implemented even before invoices are received to mitigate future losses. For example, if the established baseline variance between simulated variance and invoiced variance remains stable, it may be that the invoiced variance (e.g., 60-day lag) baseline will continue. If a sudden increase or decrease in simulated variance occurs, future invoices may be anticipated to track proportionally, so quoting systems described herein may alert a user that is responsible for making the determination whether or not to implement corrective actions in the form of applying a new coefficient to meet anticipated invoiced variance changes.

[0137] The user interface of FIG. 5 illustrates a variety of input options available to a user. Examples are shown in FIG. 5, but other input options may be present in other examples, and different user interface elements may be used. The button 506 of FIG. 5 may be selected by a user (e.g., by a touchscreen, mouse click, or other input action) to select a time range. Selecting button 506 may allow a user to input a range of dates (e.g., months). The input date range may be provided to a quoting system described herein, and the quoting system maydisplay a variance dashboard for that date range, including monthly and / or weekly variance metrics over that time period.

[0138] The button 508 of FIG. 5 may be selected by a user (e.g., by a touchscreen, mouse click, or other input action) to select one or more jurisdictions. Selecting button 508 may allow a user to input and / or select one or more jurisdictions (e g., countries). The input jurisdiction(s) may be provided to a quoting system described herein, and the quoting system may display a variance dashboard for that jurisdiction, including monthly and / or weekly variance metrics over a time period. For example, the quoting system 106 of FIG. 1 may determine per-jurisdiction metrics using selected records in the variance data storage 128 associated with the selected jurisdictions. In some examples, records may be identified as associated with the selected jurisdictions based on having a particular prefix of their HS code particular to that jurisdiction.

[0139] The button 510 of FIG. 5 may be selected by a user (e.g., by a touchscreen, mouse click, or other input action) to set one or more thresholds. Selecting button 510 may allow a user to input and / or select one or more thresholds. The thresholds may be provided to a quoting system described herein, and the quoting system may utilize the thresholds to vary the coefficient generation process and / or user interface display parameters. Generally, any threshold described herein may be set by a user using an interface such as shown in FIG. 5. In some examples, a target variance may be input by a user using button 510.

[0140] Referring back to FIG. 4, recall that, following calculation of one or more coefficients, one or more conversion sensitivity' scores may be calculated. Generally, a conversion sensitivity score may be a numerical metric that may provide an indication of an impact a coefficient may have on conversion (e.g.. future transactions). The conversion sensitivity score may be calculated for a particular jurisdiction, for a particular item, or for a particular item in a particular jurisdiction. Calculating a conversion sensitivity score may utilize one or more thresholds set by a user based on risk appetite. Based on the conversion sensitivity score, one or more actions may be taken (e.g., guardrails applied) to the initial coefficient recommended by the system. Coefficients may be implemented in a manner in accordance with their conversion sensitivity scores.

[0141] FIG. 6 is a flowchart illustrating a method for calculating conversion sensitivity scores. The method may be implemented, for example, by quoting system 106 of FIG. 1 (e.g., by coefficient calculator 130 and / or computer system 114). The method of FIG. 6 includes block 604, which recites “receive variance data and proposed coefficient(s).” Block 604 may be followed by block 606, which recites “for each jurisdiction variance data, and each item.”Block 606 may be followed by block 608. which recites “calculate conversion sensitivity score.” Block 608 may be followed by block 610, which recites “store sensitivity score.” FIG. 6 further illustrates a table representing a rule-based mechanism for calculating the conversion sensitivity score in block 608.

[0142] The calculation of conversion sensitivity scores may utilize variance data and proposed coefficients. For example, the variance data and coefficients shown and described with reference to FIG. 4 and FIG. 1 may be used in block 604. The quoting system 106 may access variance data storage 128 to obtain the variance data in block 604. Block 606 specifies that the variance data and coefficients may be accessed for a particular jurisdiction and / or a particular item.

[0143] The conversion sensitivity score may be calculated in block 608 of FIG. 6. e.g., by quoting system 106 of FIG. 1. The conversion sensitivity score may be calculated using a rules-based technique. An example of rules w hich may be used to calculate sensitivity scores is shown in a table in FIG. 6. As an initial matter, the quoting system 106 may determine whether a minimum record threshold is met. For example, the quoting system 106 may access data 118 and / or variance data storage 128 to determine if over a threshold number of transactions and / or variance records are stored for the particular jurisdiction and / or jurisdiction-item pair. If not, in some examples, the proposed coefficients will not be used by the quoting system to modify further resource calculations.

[0144] Provided over a threshold number of records are present in some examples, the quoting system 106 may next determine whether the item, jurisdiction, or item-jurisdiction pair has an average sales price (ASP) over a threshold. If the ASP is over a threshold (e.g., “high”), then a relatively high sensitivity score may be calculated (e.g.. in an upper half of a range of potential sensitivity scores).

[0145] If the ASP is not over a threshold, the quoting system 106 may next determine whether the jurisdiction has transaction volumes above a threshold. If the jurisdiction volume is over a threshold (e.g., high), then a relatively high sensitivity score may be calculated.

[0146] If the jurisdiction transaction volume is not above the threshold, the quoting system 106 may next determine whether existing resource calculations had been overestimates or underestimates. If overestimates, then there may be no guardrail or adjustment operation for negative coefficients (e.g., coefficients to reduce the resource calculation amount). If underestimates, there may be a relatively low conversion sensitivity score.

[0147] Generally, a high conversion sensitivity score (e.g., above a threshold) may result in a guardrail being implemented on the coefficient. An example of a guardrail operation maybe a limit on the magnitude of the coefficient use. For example, quoting systems and / or calculators described herein may reduce a coefficient by a particular amount or percent responsive to a sensitivity score above a threshold. In some examples, a sensitivity score higher than another threshold may be transmitted for further review.

[0148] In the table of FIG. 6, an example set of rules is specified. If a minimum data threshold is not met, a sensitivity score of 0 may be calculated - regardless of ASP, volume, and over / underestimates. As a result, the disposition of the proposed coefficient is to cancel the coefficient and not use it for future resource calculations.

[0149] If the minimum data threshold is met, and there have been overestimates of the resource calculation, a sensitivity score of -1 may be calculated - regardless of ASP and volume. As a result, the disposition of the proposed coefficient is that there may be little risk, and the coefficient may be automatically used by the quoting system 106 to generate subsequent resource calculations.

[0150] If the minimum data threshold is met, and there is a high ASP and high volume, and there are underestimates, a relatively high sensitivity score (e.g., 7-10) is calculated. The disposition of the proposed coefficients is that a high conversion risk guardrail operation may be implemented (e.g., transmission for review).

[0151] If the minimum data threshold is met, and there is ASP under a threshold, and volume under a threshold, and underestimates, a medium sensitivity score may be calculated (e.g., 3- 6). The disposition of the proposed coefficients is to apply a low- or medium-risk guardrail. A low-or medium-risk guardrail operation may include, for example, reducing a magnitude of the proposed coefficients.

[0152] If the minimum data threshold is met, and there is ASP under a threshold, and volume under a threshold, and either over- or underestimates, a low sensitivity score may be calculated (e.g., 1-3). The disposition of the proposed coefficients may be to implement a low conversion risk guardrail. A low conversion risk guardrail operation may include capping the proposed coefficients at a particular magnitude.

[0153] If the minimum data threshold is met, and there is ASP under a threshold, and volume over a threshold, and there had been previous underestimates, a medium sensitivity score may be calculated (e.g., 4-6). The disposition of the proposed coefficients may be to apply a medium conversion risk guardrail, such as to cap the coefficients at a threshold associated with medium risk. Note that the threshold associated with medium risk may be a higher magnitude than the threshold associated with lower risk.

[0154] In block 610. conversion sensitivity scores may be stored. The scores may be stored, for example, in variance data storage 128 of FIG. 1, variance data storage 334 of FIG. 3 and / or variance data storage 402 of FIG. 4. Note that any thresholds described herein may be stored, for example, in variance data storage 128 of FIG. 1, variance data storage 334 of FIG. 3, and / or variance data storage 402 of FIG. 4. In some examples, users may input one or more thresholds. For example, one or more thresholds may be user-defined, such as by one or more merchants, and / or one or more system administrators.

[0155] FIG. 7 is a flowchart illustrating a method for adjusting and implementing coefficients in accordance with examples described herein. The example of FIG. 7 includes block 702, which recites “access sensitivity7scores.” Block 702 may be followed by block 704, which recites “determine coefficient adjustments.” Block 704 may implement coefficient adjustments based on a sensitivity7score. A matrix illustrating rules for associating sensitivity scores with coefficient adjustments is also shown in FIG. 7. Block 704 may be followed by block 706, which recites “save adjusted coefficients.” Block 706 may be followed by block 708, which recites “implement adjusted coefficients in accordance with sensitivity scores.” A matrix illustrating implementations associated with different sensitivity7scores is also shown in FIG. 7. Block 708 may be followed by decision block 710, which recites “auto implement?.” If a coefficient may be auto-implemented, decision block 710 may be followed by block 716, which recites “implement adjusted coefficients.” If a coefficient may not be auto-implemented, decision block 710 may be followed by block 712, which recites “transmit coefficient for review.” Block 712 may be followed by block 714, which recites “receive response.” Block 714 may be followed by block 716, which recites “implement adjusted coefficients.”

[0156] The operations of FIG. 7 may be performed using one or more quoting systems described herein, such as quoting system 106 of FIG. 1. The operations and matrix shown in FIG. 7 are exemplary7; additional, fewer, and / or different operations may7be performed in other examples, and different matrices and / or structures for associating coefficient operations and implementations with sensitivity scores may be used in other examples.

[0157] In block 702, a quoting system may access sensitivity scores. For example, the quoting system 106 may access sensitivity scores in variance data storage 128. The sensitivity7scores may be stored and accessed per seller, per jurisdiction, and / or per seller-jurisdiction pair.

[0158] In block 704, coefficient adjustments may be determined. In some examples, each range of sensitivity score may be associated with a particular coefficient adjustment to beperformed. Coefficient adjustments may refer to, for example, limiting the coefficient to a particular magnitude, reducing or increasing a coefficient by a particular percentage, and / or discarding the coefficient. Coefficient adjustments may be performed in a rule-based manner. Rules for implementing coefficient adjustments may be stored in, for example, data 118 of FIG. 1. variance data storage 128 of FIG. 1, or other storage accessible to quoting system 106. An example matrix showing a relationship between sensitivity score and coefficient operation (which may also be referred to as coefficient guardrail) is shown in FIG. 7. A sensitivity score of -1 is indicative of no risk in implementing the recommended coefficient. Accordingly, no coefficient operation may be associated with the negative sensitivity score. A sensitivity score of 0 may be associated with a coefficient to be cancelled. Accordingly, no coefficient operation may be associated with the sensitivity score 0. A sensitivity score from 1-3 may indicate a low conversion risk. Implementing the proposed coefficient may carry a low risk of affecting conversions for an item. Accordingly, a first limit may be imposed on proposed coefficients associated with a sensitivity score of 1-3. Proposed coefficients greater than the limit may be adjusted to equal the limit. A sensitivity score from 4-6 may indicate a medium conversion risk. Implementing the proposed coefficient may carry a medium risk of affecting conversions for an item. Accordingly, a second limit, which may be lower than the first limit, may be imposed on proposed coefficients associated with a sensitivity score of 4-6. Proposed coefficients greater than the limit may be adjusted to equal the limit. A sensitivity score from 7-10 may indicate a high conversion risk. Implementing the proposed coefficient may carry a high risk of affecting conversions for an item. Accordingly, a third limit, which may be lower than the second limit, may be imposed on proposed coefficients associated with a sensitivity score of 7-10. Proposed coefficients greater than the limit may be adjusted to equal the limit. For example, a proposed coefficient may be a recommended 10% increase to generated resource calculations. However, if the proposed coefficient was given a sensitivity score associated with a medium risk, it may be limited to a particular value (e.g., 5%). Accordingly, the coefficient may be adjusted to 5%.

[0159] In block 706, the adjusted coefficients may be stored, for example, in variance data storage 128 of FIG. 1. In block 708, a quoting system may determine how to implement coefficients in accordance with the sensitivity scores. An implementation recommendation may be determined for each jurisdiction, each seller, and / or each jurisdiction-seller pair. Coefficient implementations may be performed in a rule-based manner. Rules for implementing coefficients may be stored in, for example, data 118 of FIG. 1, variance data storage 128 of FIG. 1. or other storage accessible to quoting system 106. An example matrix showing a relationship between sensitivity score and coefficient implementation is shown inFIG. 7. A sensitivity score of -1 is indicative of no risk in implementing the recommended coefficient. Accordingly, coefficients associated with a sensitivity score of -1 may be automatically implemented. A sensitivity score of 0 may be associated with a coefficient to be cancelled. Accordingly, no coefficient implementation may be associated with the sensitivity score 0. A sensitivity score from 1-3 may indicate a low conversion risk. Implementing the proposed coefficient may carry a low risk of affecting conversions for an item. Accordingly, proposed coefficients associated with a sensitivity score of 1-3 may be auto implemented. A sensitivity score from 4-6 may indicate a medium conversion risk. Implementing the proposed coefficient may carry a medium risk of affecting conversions for an item. Accordingly, proposed coefficients associated with a sensitivity score of 4-6 may be auto implemented. A sensitivity score from 7-10 may indicate a high conversion risk. Implementing the proposed coefficient may carry' a high risk of affecting conversions for an item. Accordingly, proposed coefficients associated with a sensitivity score of 7-10 may be transmitted to another system for approval.

[0160] In decision block 710, systems described herein may determine whether autoimplementation may occur. If the quoting system 106 determined in block 706 that the proposed and / or adjusted coefficient may be auto implemented, the coefficients may be implemented in block 716. Coefficients that cannot be auto implemented may be transmitted for review in block 712. For example, the quoting system 106 may transmit the coefficients to system 102 for approval. The coefficients may be displayed, in some examples, together with a notification of risk. A user may utilize a user interface to approve the coefficient, reject the coefficient, and / or adjust the coefficient. In block 714, a response is received from the user indicative of a coefficient adjustment. The coefficient adjustment may be implemented in block 716.

[0161] In block 716, coefficients may be implemented. Coefficients may be implemented by storing the coefficients with an indication that the coefficients are to be used in generating resource calculations for a particular seller, jurisdiction, or seller-jurisdiction pair. The coefficients maybe stored in variance data storage 128. Accordingly, the quoting system 106 may utilize the coefficients in subsequent resource calculations. In this manner, subsequent resource calculations may advantageously have a reduced variance from actual resource determinations made after completion of a transaction.

[0162] Accordingly, during operation, systems described herein may manage simulated variance, actual variance, or combinations thereof. A user may in some examples specify whether to manage simulated variance, actual variance, or combinations thereof. Whengenerating resource calculations for a particular seller in a particular jurisdiction, systems described herein, such as quoting system 106, may utilize a coefficient in generating the resource calculations. The coefficient may impact the resource calculations (e.g., increase and / or decrease the calculations). The impact may be intended to reduce a variance between the calculation made at the time of the transaction and a later resource calculation performed after the transaction. After additional transactional data is obtained and / or additional carrier invoices obtained, variance may again be updated, and coefficients calculated and implemented. In this manner, fine-tuned adjustments may continuously be made to quoting system 106 in an effort to manage variance to a target, which may be a target identified by a user.

[0163] FIG. 8 is a diagram for an operational example where a buy-sell transaction 834 is a use case of the relationship instance 242. The transaction 834 is conducted between a primary entity 818, which is a seller, and a secondary entity 824, which is a buyer. The transaction 834 is therefore a buy-sell transaction between them, for instance for a physical item, but it could be a non-physical item such as a digital item, a specific right, and so on. A tax obligation 804 often arises from the transaction 834 - for example, a sales and / or use tax and / or duty may be paid by either the primary entity 818 or the secondary entity 824, and / or documents must be prepared and filed, such as tax returns, compliance forms, customs forms, importation / exportation forms, etc. A computation of the tax obligation 804 is a use case of producing the resource 212.

[0164] It will be recognized that aspects of FIG. 8 have similarities with aspects of FIG. 2. Portions of such aspects may be implemented as described for analogous aspects of FIG. 2. In particular, a computer system 822 is shown, which is used to help customers, such as a user 816. with tax compliance. For instance, the user 816 may log into the computer system 822 by using credentials, such as a username, a password, a token, and so on. Further in this example, the computer system 822 is part of an OSP 826 that is implemented as a Software as a Service (SaaS) provider, for being accessed by the user 816 online. As such, the OSP 826 can be an online service provider for clients. Alternately, the functionality of the computer system 822 may be provided locally to a user.

[0165] The user 816 may be standalone. The user 816 may use a computer system 812 that has a screen 814. In embodiments, the user 816 and the computer system 812 are considered part of the primary entity 818, which is also known as entity 818. The primary entity 818 can be a business, such as a seller of items, a reseller, a buyer, a service business, and so on. Insuch instances, the user 816 can be an employee, a contractor, or otherwise an agent of the entity 818.

[0166] The buyer 824 can be an organization, a person, and so on. The buyer 824 has a device 802 with a screen 830. The buyer 824 may have used a device such as the device 802 for the buy-sell transaction 834.

[0167] The buy-sell transaction 834 may involve an operation, such as an exchange of data to form an agreement. This operation can be performed in person, or over a network 808, which can be as described elsewhere for communications networks, etc. In such cases, the primary' entity - seller 818 can even be an online seller, but that is not necessary. The buysell transaction 834 may have data that is known to the entity 818, similarly with what was described by the relationship instance 242 of FIG. 2.

[0168] In a number of instances, the user 816 and / or the entity 818 use softw are applications to manage their business activities, such as sales, production, inventory' management, delivery, billing, and so on. The user 816 and / or the entity 818 may further use accounting applications to manage purchase orders, sales invoices, refunds, payroll, accounts payable, accounts receivable, and so on. Such software applications, and more, may be used locally by the user 816, or from an Online Processing Facility (OPF) 810 that has been engaged for this purpose by the user 816 and / or the entity 818. The OPF 810 can be analogous to the OPF 234. In such use cases, the OPF 810 can be a mobile payments system, a point of sale (POS) system, an accounting application, an enterprise resource planning (ERP) provider, an e- commerce provider, an electronic marketplace, a customer relationship management (CRM) system, and so on.

[0169] Businesses have tax obligations to various tax authorities of respective tax jurisdictions. It is often challenging to even determine what taxes are owed and to whom, because the underlying statutes and tax rules and guidance issued by the tax authorities are very complex. There are various types of tax, such as sales tax. use tax, excise tax, and value- added tax, and issues about cross-border taxation including customs and duties, among many others. Some types of tax are industry' specific. Each type of tax has its own set of rules. Additionally, statutes, tax rules, and rates change often, and new' tax rules are continuously added. Compliance becomes further complicated when a taxing authority offers a temporary tax holiday, during which certain taxes are waived.

[0170] Tax jurisdictions are defined mainly by geography. Businesses have tax obligations to various tax authorities within the respective tax jurisdictions. There are various tax authorities, such as that of a group of countries, of a single country', of a state, of a county, ofa municipality, of a city, of a local district such as a local transit district, and so on. So, for example, when a business sells items in transactions that can be taxed by a tax authority, the business may have tax obligations to the tax authority. These obligations include requiring the business to: a) register itself with the tax authority’s taxing agency, b) set up internal processes for collecting sales tax in accordance with the sales tax rules of the tax authority, c) maintain records of the sales transactions and of the collected sales tax in the event of a subsequent audit by the taxing agency, d) periodically prepare a form (“tax return”) that includes an accurate determination of the amount of the money owed to the tax authority as sales tax based on the sales transactions, e) file the tax return with the tax authority by a deadline determined by the tax authority, and f) pay (remit) that amount of money to the tax authority. In such cases, the filing and payment frequency and deadlines are determined by the tax authority.

[0171] A challenge for businesses is that software applications generally cannot provide tax information that is accurate enough for the businesses to be tax compliant with all the relevant tax authorities. The lack of accuracy may manifest itself as errors in the amounts determined to be owed as taxes to the various tax authorities, and it is not good to have such errors. For example, businesses that sell products and services have risks whether they overestimate or underestimate the sales tax due from a sale transaction. On the one hand, if a seller overestimates the sales tax due, then the seller collects more sales tax from the buyers than was due. Of course, the seller may not keep this surplus sales tax, but instead must pay it to the tax authorities - if the seller cannot refund it to the buyers. If a buyer later learns that they paid unnecessarily more sales tax than was due, the seller risks at least harm to their reputation. Sometimes the buyer will have the option to ask the state for a refund of the excess tax by sending an explanation and the receipt, but that is often not done as it is too cumbersome for the amounts of money involved. On the other hand, if a seller underestimates the sales tax due, then the seller collects less sales tax from the buyers, and therefore pays less sales tax to the authorities than was actually due. That is an underpayment of sales tax that will likely be discovered later, if the tax authority audits the seller. Then the seller will be required to pay the difference, plus fines and / or late fees, because ignorance of the law is not an excuse. Further, one should note that sales taxes can be considered trust-fund taxes, meaning that the management of a company may be held personally liable for the unpaid sales tax.

[0172] For sales in particular, making correct determinations for sales and use tax is even more complex, and therefore difficult. There are a number of factors that contribute to the complexity.

[0173] First, some state and local tax authorities have origin-based tax rules, while others have destination-based tax rules. Accordingly, a sales tax may be charged from the seller’s location, meaning according to the rules of the tax authority7of the seller, or from the buyer’s location, meaning according to the rules of the tax authority of the buyer.

[0174] Second, the various tax authorities assess different, e.g., non-uniform, percentage rates of the sales price as sales tax, for the purchase and sale of items that involve their various tax jurisdictions. These tax jurisdictions include various states, counties, cities, municipalities, special taxing jurisdictions, and so on. As the United States switched, largely but not completely, from primarily origin-based sales tax to destination-based tax, the number of tax jurisdictions rapidly multiplied, and the incentives for local governments to implement new and varied tax rules and ever smaller jurisdictions multiplied. As such, there are over 10,000 different tax juris dictions in the US, with many partially overlapping. Their sizes vary from as large as many square miles to as small as a single building. In parallel, tens of thousands of tax rules and tax rates have been developed.

[0175] Third, in some instances, no sales tax is due at all because of the type of item sold. For example, in 2018, the sale of cowboy boots was exempt from sales tax in Texas, but not in New York. This non-uniformity gives rise to numerous individual taxability rules related to various products and services across different tax jurisdictions.

[0176] Fourth, in some instances, no sales tax is due at all because of who the individual buyer is, and / or what the purchase is for. For example, certain entities are exempt from paying sales tax on their purchases, as long as they properly create and sign an exemption certificate and give it to the seller for each purchase made. Entities that are entitled to such exemptions may include wholesalers, resellers, non-profit charities, educational institutions, etc. Of course, who can be exempt is not exactly the same in each tax jurisdiction. And, even when an entity is entitled to be exempt, different tax jurisdictions may have different requirements for the certificate of exemption to be issued and / or remain valid. And, certificates of exemption may expire after some time, and may need to be renewed or reissued.

[0177] Fifth, it can be hard to determine which tax authorities a seller owes sales tax to. A seller may start with tax jurisdictions that it has a physical presence in, such as a main office, a distribution center or warehouse, an employee working remotely, and so on. Such ties with a tax jurisdiction establish the so-called physical nexus. However, a tax authority such as a state or even a city may set its own nexus rules for when a business is considered to be “engaged in business” with it, and therefore that business is subject to registration and collection of sales taxes. These nexus rules may include different types of nexus, such asaffiliate nexus, click-through nexus, cookie nexus, economic nexus with thresholds, and so on. For instance, due to economic nexus, a remote seller may owe sales tax for sales made in the jurisdiction that are a) above a set threshold volume, and / or b) above a set threshold number of sales transactions.

[0178] Sixth, as described herein, HS codes may be used to classify items transacted in buysell transaction 834. The HS codes may implicate taxes and / or duties owed in a cross-border transaction. However, the HS code classification system is complex, and there may be imperfect information about the transacted items at the time of the transaction. Still further, taxes and duties (which may be partially based on the HS code) may be collected from a buyer at the time of a transaction. If a more accurate HS code is later found, and / or unexpected taxes and / or duties are assessed, it may be a risk for the seller who would have profits impacted by the increased assessed taxes and / or duties.

[0179] The economic nexus mentioned above can be even more complicated. Even where a seller might not have reached any of the thresholds for economic nexus, a number of states are promulgating marketplace facilitator laws that sometimes use such thresholds. According to such laws, intermediaries that are characterized as marketplace facilitators per laws of the state may have an obligation, instead of the seller, to collect sales tax on behalf of their sellers, and remit it to the state. The situation becomes even more complex when a seller sells directly to a state, and also via such an intermediary.

[0180] To help with such complex determinations, the computer system 822 may be specialized for tax compliance. For instance, the computer system 822 thus implements a tax engine 806 to make the determinations of tax obligations. The tax engine 806 can be implemented by and / or used to implement the service engine 214 and / or quoting system 106 or computer system 114 of FIG. 1.

[0181] For a specific determination of a tax obligation, the computer system 822 may receive one or more datasets. A sample received dataset 838 is shown. The dataset 838 has parameters that can also be called dataset parameters, some of which can have respective dataset values, and can be otherwise examples of what was described for the dataset 240 of FIG. 2. In this example, the computer system 812 transmits a request that includes a payload, and the dataset 838 is received by the computer system 822 parsing the received payload. In this example, the single payload encodes the entire dataset 838, but that is not required.

[0182] In this example, the dataset 838 has been received because it is desired to determine any tax obligations arising from the buy-sell transaction 834. As such, the sample received dataset 838 has dataset parameters with values that characterize attributes of the buy-selltransaction 834. as indicated by a correspondence arrow 840. Accordingly, in this example, the sample received dataset 838 has a parameter ID with a value for an identity of the dataset 838 and / or the transaction 834. The dataset 838 also has a parameter PE with a value for the name of the primary entity 818 or the user 816, which can be the seller making sales transactions, some perhaps online. The dataset 838 further has an optional parameter PD with a value for relevant data of the primary entity 818 or the user 816, such as an address, place(s) of business, prior nexus determinations with various tax jurisdictions, and so on. The parameter PD is optional because it may be possible to look up its value from the parameter PE. The dataset 838 also has a parameter SE with a value for the name of the secondary entity- 824, which can be the buyer. The dataset 838 further has a parameter SD with a value for relevant data of the secondary entity 824, entity-driven exemption status, and so on. In some instances, the parameter SD is optional, similarly with the parameter PD. The dataset 838 has a parameter B2 with a numerical value for the sale price of the item sold. The dataset 838 may further have additional dataset parameters, as indicated by the dot-dot-dot in the right side of the dataset 838. These parameters may characterize further attributes, such as what item was sold, for example, by a Stock Keeping Unit (SKU), how many units of the item were sold in the transaction 834, a date and possibly also time of the transaction 834, and so on.

[0183] Then the computer system 822 may produce the tax obligation 804, which is analogous to producing the resource 212 of FIG. 2. The tax obligation 804 may again be determined, after the transaction, by customs authority- 832. In some instances, the tax obligation 804 may be less than or more than the tax and / or duty assessed by the customs authority 832. Examples of systems described herein may apply coefficients to the calculation of tax obligation 804 to reduce variance between the calculated tax obligation 804 and the eventual assessed tax and / or duty.

[0184] Carrier invoices may be provided by the customs authority 832 to the OSP 826, such as invoice data 820. As described herein, the invoice data 820 may be used to determine a variance between calculated tax obligation 804 and assessed tax and / or duty- by the customs authority 832.

[0185] A digital tax content may be further implemented within the OSP 826. The digital tax content can be a utility that stores digital tax rules for use by the tax engine 806. As part of managing the digital tax content, there may be continuous updates of the digital tax rules by inputs gleaned from a set of different tax authorities. Updating may be performed by humans, or by computers, and so on. As mentioned above, the number of the different tax authorities in the set may be very- large. In such use cases, tax jurisdictions such as a country-,a state, a county, a city, a municipality, etc. correspond to domains and / or jurisdictions discussed herein.

[0186] For a specific determination of a tax obligation, the computer system 822 may receive one or more datasets and implement digital tax rules. The digital tax rules are digital in that they are implemented for use by software. The digital tax rules can be created so as to accommodate legal tax rules that the set of different tax authorities promulgate to apply within the boundaries of their tax jurisdictions. The digital tax rules can be created, for example, to calculate taxes and / or duty for the buy-sell transaction 834. The digital rules may be modified to manage variance as described herein.

[0187] The computer system 822 may thus select a certain rule responsive to one or more of the dataset values of the dataset parameters of the dataset. For example, it may be recognized that a condition of the digital tax rule is met by one or more of the values of the dataset parameters of the dataset. For instance, it can be further determined that, at the time of the sale, the buyer 824 is located within the boundaries of a tax jurisdiction, that the seller 818 has nexus with that tax jurisdiction, that there is no tax holiday, and that one or more items were sold in the buy-sell transaction 834.

[0188] As such, the computer system 822 may produce the tax obligation 804. The tax obligation 804 can be produced by the computer system 822 applying the certain digital tax rule. In this example, the identified certain digital tax rule may specify that a tax and / or duty is due, that the amount is to be determined by a multiplication of the sale price of the value of the parameter B2 by a specific rate, the tax return form that needs to be prepared and filed, a date by which it needs to be filed, and so on. In some examples, the calculation performed by the digital tax rule is modified by one or more coefficients in the manner discussed herein.

[0189] The computer system 822 may then cause a notification to be transmitted. The notification may be caused to be transmitted by the computer system 822 as an answer to the received dataset 838. The notification can be about an aspect of the tax obligation 804. For instance, the notification may inform that the tax obligation 804 has been determined, where it can be found, what it is, or at least a portion or a statistic of its content, and so on.

[0190] The notification can be transmitted to one of an output device and another device that can be the remote device, from which the dataset was received. The output device may be the screen of a local user or a remote user. The notification may thus cause a desired image to appear on the screen, such as within a graphical user interface (GUI), and so on. The other device may be a remote device, as in this example. In particular, the computer system 822 causes the notification to be communicated by being encoded as a payload, which is carriedby a response. The response may be transmited via a communications network 808 responsive to the received request. The response may be transmitted to the computer system 812, or to the OPF 810, and so on. As such, the other device can be the computer system 812, or a device of the OPF 810, or the screen 814 of the user 816, and so on. In this example the single payload encodes the entire notification, but that is not required. Of course, along with the aspect of the tax obligation 804, it may be advantageous to embed in the payload the ID parameter and / or one or more additional parameters of the dataset. This will help the recipient correlate the response that they receive to their request, and therefore match the received aspect of the tax obligation 804 as the answer to the transmitted dataset.

[0191] The digital tax rules can be implemented or organized in different ways. For example, these digital tax rules may have applicability conditions that relate to geographical boundaries, effective dates with possible temporary exceptions, item classification into categories, differently treated parties, and so on, for determining where and when a certain digital tax rule is to be selected and applied, to determine the tax obligation 804. These conditions may be expressed as logical conditions with ranges, dates, other data, and so on. Values of the dataset parameters of the dataset can be iteratively tested against these logical conditions. In such cases, the applicable tax rules may indicate how to compute one or more tax obligations, such as to indicate different types of taxes that are due, rules, rates, exemption requirements, reporting requirements, remittance requirements, the actual amounts of tax obligations, etc.

[0192] The digital tax rules may also be complex. While a certain one of these digital resource rules is eventually selected and applied to determine the tax obligation, more than one of them may be used for selecting that certain one.

[0193] FIG. 9 is a diagram showing details and aspects of different types of possible embodiments of the digital tax rules of the use cases of FIG. 8.

[0194] Referring now to FIG. 9. a dataset 902 can be as described for the dataset 838 of FIG. 8. In addition, a set 906 of digital tax rules is an example of the digital tax rules described in connection with FIG. 8. A tax obligation 904 can be produced according to the arrow 950. The tax obligation 904 can be as described for the tax obligation 804.

[0195] The set 906 of digital tax rules shows examples for digital tax rules, such as the digital tax rules of FIG. 8. The set 906 of digital tax rules includes different subsets, into which the individual rules belong. In addition, there can be hierarchical relationships among rules of different subsets, and / or of types. In this example, the set 906 includes a subset 936 of tax authority selecting rules. The set 906 also includes subsets 944, 910, 908, ... , each fordigital tax rules for tax authorities A. B. C, respectively. A tax authority for which a subset of tax rules is thus provided could be associated with the primary entity -sell er 818, another tax authority could be associated with the secondary7entity -buyer 824, and so on. In cases where digital tax rules are provided only for the tax authority' A, the tax obligation 904 will be determined by starting from an arrow 952a.

[0196] The subset 936 includes rules 938, 940, 942, ... . The subset 936 may be invoked, e.g., per an arrow 952b, when multiple jurisdictions are candidates. These rules may select which tax jurisdiction's rules will be applied, e.g., per an arrow 952c. For instance, the rules of the subset 936 may be used to resolve whether a sales tax determination will be originbased or destination-based. This may depend on appropriate rules of the tax jurisdictions themselves. Then the rules of the subset 936 may point to the digital tax rules of one or more tax authorities whose legal tax rules must be followed. For instance, and as mentioned above, a buy-sell transaction may be burdened by a sales tax from the tax jurisdictions of a state and of a city. These could invoke, respectively, the subsets 944 and 910.

[0197] Digital tax rules for individual tax authorities are now described. Such rules need not be the same for each tax authority, or of the same type for each domain. The sample subset 944 of digital tax rules for tax authority A is now described in more detail. Its description can be similar for subsets for other domains, such as the subsets 910, 908, ... .

[0198] The subset 944 includes different types of rules. In this example, the subset 944 includes tax precedence rules 912, tax computation rules 920, and tax override rules 928. In this example, the tax precedence rules 912 include rules 914, 916, 918, ... . The tax computation rules 920 include rules 922, 924, 926, ... . The tax override rules 928 include rules 930, 932, 934. ... . While the term ‘lax rules" is used herein, it is to be understood that the tax rule may be used to calculate a tax and / or a duty.

[0199] In embodiments, one of the tax computation rules 920 may ordinarily be selected as the certain digital tax rule. For instance, it may specify a percentage tax rate for the sales tax. The tax obligation 904 may be the percentage rate. Or the purchase price (base value of the parameter B2) may be further learned from the dataset 902, e.g., per an arrow 952d, and the tax obligation 904 may be the sales tax amount, produced by multiplying the percentage rate by the purchase price. The digital tax rule may specify computation of a duty. The duty may be calculated based on an HS code as described herein. Use of the rule may be modified by coefficients, which may be generated and implemented as described herein.

[0200] In addition, although not always required, the different types of rules within the subset 944 further have different hierarchies among them.

[0201] For a first instance, one of the tax precedence rules 912 may indicate which one of the tax computation rules 920 is to be selected, as generally indicated by an arrow 948. As an example, one of the tax precedence rules 912 may decide the taxability of a specific item indicated in the dataset 902. Such a tax precedence rule may implement, therefore, an item classification task. The answer can be no sales tax, or different sales tax depending on different categories. For instance, bagels may be taxed differently depending on whether or not they are sold with utensils, whether or not they are pre-sliced when sold, and so on. Then the precedence rule may indicate which one of the tax computation rules 920 is the appropriate one to use for the computation of the sales tax. As another example, one of the tax precedence rules 912 may indicate that there is a temporary sales tax holiday in a tax jurisdiction on the day of the transaction, in which case the sales tax for the buy-sell transaction 834 will be zero, and the tax obligation will be computed accordingly. As one more example, one of the tax precedence rules 912 may indicate that there is no economic nexus for this transaction which, alone or in combination with other nexus determinations, may determine that no sales tax will be imposed.

[0202] For a second instance, even when one of the tax computation rules 920 is thus indicated, one of the tax override rules 928 may still override the indication, as generally indicated by an arrow 946. As an example, one of the tax override rules 928 may indicate that a party is exempt from paying sales tax because certain conditions are met, for instance, if they have a valid and current exemption certificate. As another example, rules for implementing cases where the sales tax computation is overridden and no sales tax is due, such as with a tax holiday or lack of economic nexus, may instead be implemented as the tax override rules 928.EXAMPLE

[0203] To facilitate appreciation of the systems and methods described herein, an example of a resource calculation and coefficient use will now be numerically described. It is to be understood that this example describes only one implementation of example described systems and methods. Other examples may utilize different numbers or different processes as described herein.

[0204] In this example, duty may be calculated as a duty rate multiplied by a dutiable value. The calculation may be performed by quoting systems described herein. The duty rate may be associated with an HS code. Accordingly, the calculation may vary based on HS code determined before completion of a transaction, after a transaction, and by a third party (e.g., carrier). Examples of the duty rate include 15%, 12%, and 5%, but other duty rates may beused. The dutiable value of a product may be the sum of the product cost, insurance, and freight charges. Other factors may be included in dutiable value in other examples. Quoting systems described herein may calculate and / or estimate dutiable value.

[0205] Taxes may be calculated as a taxable value multiplied by the sum of a VAT rate (if applicable, for a particular jurisdiction, such as a region, state, and / or province) and an additional tax rate (if applicable). These taxes may be calculated by quoting systems described herein, and the relevant VAT rates and / or additional tax rates may be stored in storage accessible to quoting systems described herein, such as data storage 118 of FIG. 1. The taxable value may be equal to the sum of a dutiable value plus duty (if applicable) and customs fees (if applicable). An example VAT rate is 12%, although other rates may be used. An HS code may be used by quoting systems described herein to determine if an item is VAT and / or GST tax free - as an example, books may be VAT and / or GST tax free. An HS code may be used by quoting system described herein to determine the applicability of other taxes (e.g., excise tax, luxury tax). An association between HS codes and applicable taxes may be stored in storage devices described herein, such as storage 118 of FIG. 1.

[0206] In an example operation of a system described herein, a user may set a variance target. In this example, a variance target may be 3%. An example quoting system may perform operations generally described with reference to FIGS. 3 and 4 to determine variance. For example, in a one-month time period (e.g., January) in a jurisdiction (e.g.. EU), historical estimated duty for sold items may total $26,669. Actual invoiced duties for those transactions in that time period may have been $22,253. Accordingly, the actual variance may be $26,669 - $22,253 = $4,416.

[0207] Quoting systems described herein may determine a coefficient that, when applied to the historical estimates, may provide a revised estimate that would have achieved a 3% variance. Accordingly, the new estimate would be the target (e.g., 0.03) multiplied by the actuals summed with the actuals. So, in this example ((0.03)*$22,253) + $22,253 = $22,921. Quoting systems may determine a coefficient which, when multiplied by the original estimates, provides the new estimates. Coefficient = new estimate / original estimate = $22,921 / $26,669 = 0.86. The quoting system may verify that this coefficient multiplied by the original estimates yields the new estimates. The quoting system may verify that the new variance is equal to the new estimates minus the actuals, and that that variance meets the defined target. After verification, the calculated coefficient may be a proposed coefficient from the quoting system. In some examples, the coefficient may be implemented based on a sensitivity score as generally described with reference to FIGS. 5-7 herein.

[0208] Software aspects of embodiments may include instructions for processors, methods of operation, datasets, interfaces, user interfaces (UIs), applications, Application Programming Interfaces (APIs), connectors, and the like.

[0209] Software aspects or modules of embodiments can be hosted on any suitable machine, anywhere. For example, such software aspects can be hosted on a computer system, a desktop computer, an on-location server, a machine that is located remotely to where other processes are executed, such as in the cloud or on the premises of a provider, a memory of such, and so on. The software can be accessible by a user via a browser, a UI, an API, etc. Depending on where they are hosted, some software components or modules can be considered a client, etc.

[0210] Although the operational and or functional descriptions of this document are understandable by the human mind, they are not abstract ideas of the operations / functions divorced from computational implementation of those operations / functions. Rather, the operations / functions represent a specification for complex computational machines or other means. As discussed in detail elsewhere in this document, each operational / functional language must be read in its proper technological context, e.g., as concrete specifications for physical implementations. Far from being understood as an abstract idea, it can be recognized that a functional / operational technical description is a humanly understandable representation of one or more almost unimaginably complex and time-sequenced hardware instantiations.

[0211] Moreover, the methods, algorithms, operations, functions, and acts described in this document are not necessarily inherently associated with any particular logic device or other apparatus. Rather, they are advantageously implemented by programs for use by any of the devices or systems described in this document. These algorithms are not necessarily purely mathematical, and are configured to address challenges particular to the problem solved, as will be apparent to a person skilled in the art.

[0212] This detailed description may include flowcharts, display images, algorithms, and symbolic representations of program operations within at least one computer readable medium. An economy may be achieved in that a single set of flowcharts can be used to describe both programs, and also methods. So, while flowcharts describe methods in terms of boxes, they may also concurrently describe programs.

[0213] In examples of methods described herein, each operation can be performed as an affirmative step of doing, or causing to happen, what is written that can take place. Such doing or causing to happen can be by the whole system or device, or just one or more components of it. In addition, the order of operations is not constrained to what is shown, and different orders may be possible according to different embodiments. Moreover, incertain embodiments, new operations may be added, or individual operations may be modified or deleted. The added operations can be, for example, from what is mentioned while primarily describing a different system, apparatus, device, or method.

[0214] This description includes one or more examples, but that does not limit how the technology may be practiced. Indeed, examples or embodiments may be practiced according to what is described, or yet differently, and also in conjunction with other present or future technologies. Other embodiments include combinations and sub-combinations of features described or shown in the drawings herein, including, for example, embodiments that are equivalent to: providing or applying a feature in a different order than in a described embodiment, extracting an individual feature from one embodiment and inserting such feature into another embodiment; removing one or more features from an embodiment; or both removing one or more features from an embodiment and adding one or more features extracted from one or more other embodiments, while providing the advantages of the features incorporated in such combinations and sub-combinations. As used in this paragraph, feature or features can refer to the structures and / or functions of an apparatus, article of manufacture or system, and / or the steps, acts, or modalities of a method.

[0215] This description is to be taken as a whole. Details have been included to provide a thorough understanding. In other instances, well-known aspects have not been described, in order to not obscure unnecessarily the described examples. Any reference to prior systems in this description is not, and should not be taken as, an acknowledgement or any form of suggestion that the prior system discussed is prior art. Any reference to any prior art in this description is not, and should not be taken as, an acknowledgement or any form of suggestion that this prior art forms parts of the common general knowledge in any country.

Claims

CLAIMSWhat is claimed is:

1. A method comprising: generating, by a quoting system, a first resource calculation for an instance associated with an item and a jurisdiction, the first resource calculation using a first classification of the item; receiving, at the quoting system, a second classification of the item; generating, by the quoting system, a second resource calculation for the instance associated with the item and the jurisdiction, the second resource calculation using the second classification of the item; calculating, by the quoting system, a simulated variance between the first resource calculation and the second resource calculation; and generating, by the quoting system, and based on the simulated variance, a coefficient for use in calculating a subsequent resource calculation for a subsequent instance associated with the item and the jurisdiction.

2. The method of claim 1, further comprising adjusting, by the quoting system, the coefficient based on an estimated impact of the coefficient on a number of subsequent resource calculations.

3. The method of claim 2, wherein said adjusting comprises calculating, by the quoting system, a sensitivity score based, at least in part, on a volume of expected instances of the item and the jurisdiction.

4. The method of claim 3, wherein said adjusting comprises adjusting the coefficient by an amount based, at least in part, on the sensitivity score.

5. The method of claim 3, further comprising notifying, by the quoting system, a user when the sensitivity score exceeds a threshold.

6. The method of claim 5, further comprising: receiving, from the user, a response to said notifying; and wherein said adjusting is further based on the response.

7. The method of any one of the preceding claims, wherein said generating the first resource calculation comprises using machine learning to generate the first resource calculation.

8. The method of any one of the preceding claims, wherein said generating the second resource calculation comprises receiving the second classification from a secondary system.

9. The method of any one of the preceding claims, further comprising: receiving, at the quoting system, a third resource calculation for the instance associated with the item and the jurisdiction; calculating, by the quoting system, an actual variance between the first resource calculation and the third resource calculation; and wherein said generating the coefficient is further based on the actual variance.

10. The method of claim 9, further comprising: generating a key for the first resource calculation; and utilizing the key, at the quoting system, to associate the first resource calculation with the third resource calculation.

11. The method of any one of the preceding claims, further comprising: performing the subsequent resource calculation; and displaying a result of the subsequent resource calculation.

12. At least one computer readable media encoded with instructions which, when executed by one or more processors, cause a computing system to perform operations comprising: generating a first resource calculation for an instance associated with an item and a jurisdiction, the first resource calculation using a first classification of the item; receiving a second classification of the item; generating a second resource calculation for the instance associated with the item and the jurisdiction, the second resource calculation using the second classification of the item; calculating a simulated variance between the first resource calculation and the second resource calculation; and generating, based on the simulated variance, a coefficient for use in calculating a subsequent resource calculation for a subsequent instance associated with the item and the jurisdiction.

13. The computer readable media of claim 12. wherein the operations further comprise: adjusting the coefficient based on an estimated impact of the coefficient on a number of subsequent resource calculations.

14. The computer readable media of claim 13. wherein said adjusting comprises calculating a sensitivity score based, at least in part, on a volume of expected instances of the item and the jurisdiction.

15. The computer readable media of claim 14. wherein said adjusting comprises adjusting the coefficient by an amount based, at least in part, on the sensitivity score.

16. The computer readable media of claim 14. wherein the operations further comprise: notifying, by the quoting system, a user when the sensitivity score exceeds a threshold.

17. The computer readable media of claim 16, wherein the operations further comprise: receiving, from the user, a response to said notifying; and wherein said adjusting is further based on the response.

18. The computer readable media of any one of the preceding claims, wherein said generating the first resource calculation comprises using machine learning to generate the first resource calculation.

19. The computer readable media of any one of the preceding claims, wherein said generating the second resource calculation comprises receiving the second classification from a secondary system.

20. The computer readable media of any one of the preceding claims, wherein the operations further comprise: receiving a third resource calculation for the instance associated with the item and the jurisdiction; calculating an actual variance between the first resource calculation and the third resource calculation; and wherein said generating the coefficient is further based on the actual variance.

21. The computer readable media of claim 20, wherein the operations further comprise: generating a key for the first resource calculation; and utilizing the key to associate the first resource calculation with the third resource calculation.

22. The computer readable media of any one of the preceding claims, wherein the operations further comprise: performing the subsequent resource calculation; and displaying a result of the subsequent resource calculation.

Images