Identification of candidate data for resource calculations arising from transactions
An online software platform enhances resource obligation calculations by comparing transaction data with historical data, using machine learning to identify candidate data and query client systems, addressing incomplete data issues and improving accuracy and compliance.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- AVALARA INC
- Filing Date
- 2024-11-04
- Publication Date
- 2026-05-07
AI Technical Summary
Existing software systems struggle to accurately calculate complete resource obligations due to incomplete transaction data, as invoicing systems often fail to provide all necessary information, leading to inefficiencies and inaccuracies in resource calculation.
An online software platform receives transaction data, compares it with historical data, identifies candidate data using machine learning, and queries client systems for additional data to enhance resource obligation calculations, improving data coherence and completeness.
This approach enables more accurate and comprehensive resource calculations, reducing computational intensity and expert training needs at other systems by identifying and obtaining missing data, ensuring compliance with tax rules across jurisdictions.
Smart Images

Figure US2024054452_07052026_PF_FP_ABST
Abstract
Description
0077888-00200 (AVAPAT_199)IDENTIFICATION OF CANDIDATE DATA FOR RESOURCE CALCULATIONS ARISING FROM TRANSACTIONSTECHNICAL FIELD
[0001] This application relates to software systems for performing resource calculations. Examples of systems may calculate candidate data which may be used to calculate additional resource obligations arising from a transaction.BACKGROUND
[0002] Increasingly, businesses utilize software services to manage data of an enterprise, and to perform calculations based on the data of the enterprise. For example, enterprise resource planning (ERP) systems help businesses collect information relating to their operations, such as production, resource management, inventory management, sales, delivery, billing, and other operations. Similarly, accounting software applications help businesses with their accounting information, such as payroll, purchase orders, accounts payable, sales invoices, accounts receivable, and so on.
[0003] For example, invoicing software systems may be used by enterprises. The invoicing software system may record certain structured data regarding transactions made by or with the enterprise. Other systems may utilize the data from the invoicing software system to calculate or determine other resource obligations for the enterprise (e.g., taxes and / or fees). However, invoicing systems may not be designed to record or provide all information that may be advantageous for other systems to use in calculating resource obligations. Accordingly, other software systems relying on data provided by the invoicing system may have insufficient information to fully calculate the resource obligations of the enterprise.
[0004] All subject matter discussed in this Background section of this document is not necessarily prior art, and may not be presumed to be prior art simply because it is presented in this Background section. Plus, 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 such prior art forms parts of the common general knowledge in any art in any country. Along these lines, any recognition of problems in the prior art discussed in this Background section or associated with such subject matter should not be treated as prior art, unless expressly stated to be prior art. Rather, the discussion of any subject matter in this Background section should be treated as part of the approach taken towards the particular problem by one or more inventors. This approach in and of itself may also be inventive.0077888-00200 (AVAPAT_199)SUMMARY
[0005] In an example aspect, a method includes receiving, at an online software platform, transaction data for an entity, calculating, by the online software platform, resource obligations associated with the transaction data, comparing the transaction data with historical transaction data associated with additional entities, the historical transaction data stored in storage accessible to the online software platform, identifying, based on said comparing, candidate data associated with the transaction data, where the candidate data causes at least one additional resource obligation, searching for authorization to obtain the candidate data based on the identifying, and responsive to accessing the authorization, querying a client system for the candidate data.
[0006] The method may also include where said identifying includes inferring, using a machine learning model, the candidate data. The method may also include where said comparing includes evaluating data coherence. The method may also include where the transaction data includes data for calculation of sales tax and the candidate data includes data for calculation of excise tax. The method may also include where the transaction data includes data for calculation of sales tax and the candidate data includes data for calculating a tax based on an insurance premium. The method may also include where the authorization is received through a user interface requesting authorization to prompt a user responsive to a determination of candidate data. The method may also include where said query ing the client system for the candidate data includes configuring a connector portion of a computing system to transmit the candidate data to the online software platform.
[0007] Example methods may further include receiving feedback on the candidate data. Example methods may also include updating the machine learning model based on the feedback. Example methods may also include where said data coherence includes a likelihood of the candidate data being present in the historical transaction data together with other of the transaction data. Example methods may also include where the transaction data includes price and where the candidate data includes percentage of alcohol content.
[0008] In another example aspect, at least one non-transitory computer-readable storage medium is provided, the computer-readable storage medium including instructions that when executed by a computer, cause the computer to perform operations includes receive, at an online software platform, transaction data for an entity, calculate, by the online software platform, resource obligations associated with the transaction data, compare the transaction data with historical transaction data associated with additional entities, the historical transaction data stored in storage accessible to the online software platform, identify, based0077888-00200 (AVAPAT_199) on said comparing, candidate data associated with the transaction data, where the candidate data causes at least one additional resource obligation, search for authorization to obtain the candidate data based on the identifying, and responsive to accessing the authorization, query a client system for the candidate data.
[0009] The computer-readable storage medium may also include instructions where said identifying includes inferring, using a machine learning model, the candidate data. The computer-readable storage medium may also include instructions where said comparing includes evaluate data coherence. The computer-readable storage medium may also include instructions where the transaction data includes data for calculation of sales tax and the candidate data includes data for calculation of excise tax. The computer-readable storage medium may also include instructions where the transaction data includes data for calculation of sales tax and the candidate data includes data for calculating a tax based on an insurance premium. The computer-readable storage medium may also include instructions where the authorization is received through a user interface request authorization to prompt a user responsive to a determination of candidate data. The computer-readable storage medium may also include instructions where said querying the client system for the candidate data includes configure a connector portion of a computing system to transmit the candidate data to the online software platform,
[0010] In another example aspect, a system includes a first computer system configured to generate transaction data. The system also includes a second computer system configured to extract the transaction data from the first computer system in accordance with a particular configuration, the second computer system including a processor. The system also includes a second computer system configured to extract the transaction data from the first computer system in accordance with a particular configuration, the second computer system including a memory storing instructions that, when executed by the processor, cause the second computer system to perform operations including receive the transaction data, compare the transaction data with historical transaction data associated with additional entities, the historical transaction data stored in storage accessible to the second computer system, identify, based on said compare, candidate data associated with the transaction data, where the candidate data contributes to at least one additional resource obligation, and responsive to authorization, update the particular configuration to further extract the candidate data.
[0011] The system may also include where said identifying includes inferring, using a machine learning model, the candidate data. The system may also include where said comparing includes evaluate data coherence. The system may also include where the transaction data includes data for calculation of sales tax and the candidate data includes data0077888-00200 (AVAPAT_199) for calculation of excise tax. The system may also include where the transaction data includes data for calculation of sales tax and the candidate data includes data for calculating a tax based on an insurance premium. The system may also include where the second computer system further provides a user interface request authorization to prompt a user responsive to a determination of candidate data.BRIEF DESCRIPTION OF THE DRAWINGS
[0012] FIG. 1 is a schematic illustration of a system arranged in accordance with examples described herein.
[0013] FIG. 2 is a schematic illustration including example digital resource rules arranged in accordance with examples described herein.
[0014] FIG. 3 is a schematic illustration of a system arranged in accordance with examples described herein.
[0015] FIG. 4 is a schematic illustration of a computer system arranged in accordance with examples described herein.
[0016] FIG. 5 is a flowchart illustrating an example method arranged in accordance with examples described herein.
[0017] FIG. 6 is a schematic illustration of a system arranged in accordance with examples described herein.
[0018] FIG. 7 is a schematic illustration including example digital tax rules arranged in accordance with examples described herein.
[0019] FIG. 8 is a schematic illustration of tax calculations and scenarios arranged in accordance with examples described herein.
[0020] FIG. 9 is a schematic illustration of a user interface arranged in accordance with examples described herein.DETAILED DESCRIPTION
[0021] Examples described herein include computer systems, storage media that may store programs, and methods. Providing, in a timely and efficient manner, accurate and reliable information regarding transactions that may be used to calculate further resource obligations presents a technical problem for software systems that may be designed to calculate resource obligations based on input information in accordance with one or more sets of rules. If incoming transaction information is incomplete, it may not be possible for a software system to calculate a full scope of resource obligations for the enterprise. Because the data is provided from one software system (e.g., an invoicing system) to another (e.g., an online software0077888-00200 (AVAPAT_199) platform), it may be difficult or cumbersome for the receiving system (e.g.. the online software platform) to recognize the existence of additional data which could be used by the receiving system, but has not been provided by a providing system, such as an invoicing system.
[0022] Accordingly, providing complete information associated with a transaction for use by a resource calculation system may be difficult because the providing system may not have knowledge of the data required or usable by the resource calculation system. Moreover, it may be challenging to communicate such information in a timely and efficient manner over computer networks and in a way that integrates well into existing technical environments. This presents an additional technical problem.
[0023] The present disclosure provides examples of systems, computer readable media, and methods that may address these technical problems by increasing the speed, efficiency, and accuracy of specialized software platforms and computer networks, thus improving the technology of ERP software applications and accounting applications.
[0024] Examples of systems described herein include online software platforms that may receive transaction data for an entity. The online software platform may calculate resource obligations associated with the transaction data and compare the transaction data with historical transaction data associated with additional entities. The online software platform may identity, based on the comparison, candidate data associated with the transaction data. The candidate data may cause at least one additional resource obligation to be calculated for the transaction. The online software platform may search for authorization to obtain the candidate data based on the identifying, and, responsive to accessing the authorization, query a client system for the candidate data.
[0025] Examples of systems and methods described herein may utilize principles of data coherence to identify transaction data which may be incomplete and / or which may be able to be supplemented with additional data to result in a more complete calculation of resource obligations. By comparing incoming transaction data with other historical transaction data from one or more enterprises, systems described herein may identify additional data (which may be referred to as candidate data) that may exist and may allow the resource calculation system to calculate additional resource obligations. Note that the identification of candidate data generally refers to the identification of a type or category of data (e.g., an attribute of products, an attribute of a jurisdiction, an attribute of a service, an attribute of a party to a transaction such as a seller or a buyer). Accordingly, the term “candidate data” herein may0077888-00200 (AVAPAT_199) generally be used to refer to a category of data. If the values of the candidate data were known for the transaction, additional resource obligations may be able to be calculated.
[0026] Examples of systems and methods described herein may receive transaction data for an entity at an online software platform. The online software platform may calculate resource obligations associated with the transaction data. The online software platform may further compare the transaction data with historical transaction data associated with additional entities. For example, the historical transaction data may be stored in storage accessible to the online software platform. The online software platform may identify, based on the comparison, candidate data associated with the transaction data. The candidate data may be data that would give rise to at least one additional resource obligation. The online software platform may search for authorization to obtain the candidate data. Once authorization was obtained and / or accessed, the online software platform may query a client system for the candidate data.
[0027] In this manner, systems described herein may make more accurate resource calculations for an enterprise and / or for a transaction or set of transactions. The performance of the computer or other hardware of the online software platform may be improved, such as by allowing the system to make more complete resource calculations even given incomplete transaction data from other enterprise software systems (e.g., invoicing systems). In this manner, the processing, storage, and / or data transmission resources used by data providing systems (e.g., invoicing systems) may be less than if all the data had to be collected initially by those systems, increasing their complexity. Instead, online software platforms described herein may recognize that additional data is likely available and would result in a changed outcome (e.g., additional resource calculations).
[0028] For example, enterprise systems used to collect transaction data may be limited in their complexity, configuration, and / or expertise of their operating staff. Accordingly, only certain transaction data may be transmitted to other systems (e.g., resource calculation systems). This may result in missing information. In some examples, an invoicing system may, for example, transmit data regarding a transaction that was reported to a user. The data reported to the user (e.g., to a buyer) may, however, not be all the information which may be used in calculating resource obligations arising due to the transaction. Other information (e.g., fees or internal costs) may be used to fully calculate resource obligations. However, it may be cumbersome or impractical to redesign the invoicing system to provide this data.
[0029] For example, by identifying and obtaining additional data related to transactions, systems described herein (such as online software platforms) may be able to more accurately0077888-00200 (AVAPAT_199) and / or comprehensively calculate resource obligations created wholly or partially due to the transactions. For example, additional taxes and / or fees may be calculated by systems described herein relating to the transactions using the further identified data. In some examples, tax and / or fee calculations may be revised by systems described herein relating to the transactions using the further identified data. These additional and / or revised taxes and / or fees may cause an enterprise to be compliant with tax rules in one or more jurisdictions. In this manner, in some examples, the sophistication regarding what data may be gathered in conjunction with certain kinds of transactions (e.g., auto, liquor, real estate, commodities) may be at a centralized online software platform, reducing the need for computational intensity and / or expert training at other ERP systems (e.g., invoicing systems).
[0030] Examples of systems described herein include online software platforms that may receive transaction data for an entity. The online software platform may calculate resource obligations associated with the transaction data and compare the transaction data with historical transaction data associated with additional entities. The online software platform may identify, based on the comparison, candidate data associated with the transaction data. The candidate data may cause at least one additional resource obligation to be calculated for the transaction. The online software platform may search for authorization to obtain the candidate data based on the identifying, and, responsive to accessing the authorization, query a client system for the candidate data.
[0031] FIG. 1 is a schematic illustration of a system arranged in accordance with examples described herein. A thick horizontal line 102 separates this diagram, although not completely or rigorously, into a top portion and a bottom portion. Above the line 102 are shown elements with emphasis mostly on entities, components, their relationships, and their interactions, while below the line 102 are shown elements with emphasis mostly on processing of data that takes place often within one or more of the components that are above the line 102.
[0032] Above the line 102, a sample computer system 148 according to embodiments is shown. The computer system 148 has one or more processors 146 and a memory 104. The memory 104 stores programs 106 and data 116. The one or more processors 146 and the memory 104 of the computer system 148 thus implement a service engine 128.
[0033] The computer system 148 can be located in ‘"the cloud.” In fact, the computer system 148 may optionally be implemented as part of an Online Software Platform (OSP) 154. The OSP 154 can be configured to perform one or more predefined services, for example via operations of the service engine 128. Such services can be searches, determinations, computations, verifications, notifications, the transmission of specialized information,0077888-00200 (AVAPAT_199) 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. Such services can be provided in the form of Software as a Service (SaaS). As such, the OSP 154 can be an online software provider.
[0034] A user 142 may be standalone. The user 142 may use a computer system 138 that has a screen 140, on which User Interfaces (UIs) may be shown. In embodiments, the user 142 and the computer system 138 are considered part of a primary entity 144. In such instances, the user 142 can be an agent of the primary entity 144, and even within a physical site of the primary entity 144, although that is not necessary. In embodiments, the computer system 138 or other device of the user 142 can be client devices for the computer system 148. The user 142 or the primary' entity 144 can be clients for the OSP 154. For instance, the user 142 may log into the computer system 148 by using credentials, such as a user name, a password, a token, and so on. Generally, in examples described herein, the primary entity 144 may be an enterprise (e.g., a corporation which may be selling goods or services).
[0035] The computer system 138 may access the computer system 148 via a communication network 134, such as the internet. In particular, the entities and associated systems of FIG. 1 may communicate via physical and logical channels of the communication network 134. For example, information may be communicated as data using the Internet Protocol (IP) suite over a packet-switched network such as the Internet or other packet-switched network, which may be included as part of the communication network 134. The communication network 134 may include many different types of computer networks and communication media, including those used by various different physical and logical channels of communication, now known or later developed. Non-limiting media and communication channel examples include one or more, or any operable combination of: fiber optic systems, satellite systems, cable systems, microwave systems. Asynchronous Transfer Mode ("ATM”) systems, frame relay systems, Digital Subscriber Line (“DSL”) systems, Radio Frequency (“RF”) systems, telephone systems, cellular systems, other wireless systems, and the Internet. In various embodiments the communication network 134 can be or include any type of network, such as a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), or the internet. Accordingly, from certain perspectives, the OSP 154 is in the cloud, and is therefore depicted in FIG. 1 within the communication network 134.
[0036] 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. 1, with systems exchanging requests and responses.0077888-00200 (AVAPAT_199)
[0037] Moreover, in some embodiments, data from the computer system 138 and / or from the computer system 148 may be stored in an Online Processing Facility (OPF) 136 that can run software applications, perform operations, and so on. In such embodiments, requests and responses may be exchanged with the OPF 136, downloading or uploading may involve the OPF 136, and so on. In such embodiments, the computer system 138 and any devices of the OPF 136 can be considered to be remote devices, at least from the perspective of the computer system 148.
[0038] In some instances, the user 142 and / or the primary entity 144 have instances of relationships with secondary entities. Only one such secondary entity 150 is shown. In this example, the primary entity 144 has a relationship instance 152 with the secondary entity 150.
[0039] In some instances, the user 142 and / or the primary entity 144 obtain data about one or more secondary entities, for example as necessary for conducting the relationship instances with them. The primary entity 144 and / or the secondary entity 150 may be referred to as simply entities. One of these entities may have one or more attributes. Such an attribute of such an entity may be any one of its name, type of entity, a physical or geographical location such as an address, a contact information element, an affiliation, a characterization of another entity’, a characterization by another entity', an association or relationship with another entity (general or specific instances), an asset of the entity, a declaration by or on behalf of the entity, a specific domain that the entity belongs in a context of multiple domains that are defined in terms of the above, and so on.
[0040] In some examples, a secondary' entity 150 may be a customer. The customer may be another computer system in some examples, or may be an individual consumer. Customers may interact with primary’ entity 144 by buying and / or consuming goods or services. One or more customers may engage in transactions with the primary entity' 144. A transaction may generally refer to an exchange of goods and / or services. The computer system 138 may collect and / or store transaction data relating to the transactions.
[0041] In embodiments, the computer system 148 receives one or more datasets. A sample received dataset 110 is shown below the line 102. The dataset 110 may be received by the computer system 148 in a number of ways. In some embodiments, one or more requests may be received by the computer system 148 via a network. In this example, a request 130 is received by the computer system 148 via the network 134. The request 130 has been transmitted by' the remote computer system 138. The received one or more requests can carry payloads. In this example, the request 130 carries a payload 108. In such embodiments, the one or more payloads may be parsed by the computer system 148 to extract the dataset. In0077888-00200 (AVAPAT_199) this example, the payload 108 can be parsed by the computer system 148 to extract the dataset 110. In this example the single payload 108 encodes the entire dataset 110, but that is not required. In fact, a dataset can be received from the payloads of multiple requests. In such cases, a single payload may encode only a portion of the dataset. And. of course, the payload of a single request may encode multiple datasets. Additional computers may be involved with the network 134, some beyond the control of the user 142 or OSP 154, and some within such control.
[0042] The dataset 110 has values that can also be called dataset values. The dataset values can be numerical, alphanumeric, Boolean, and so on, as needed for what the values characterize. For example, an identity7value ID may indicate an identity of the dataset 110, 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 144 and 150, as indicated bycorrespondence arrows 156. For instance, a value DI may be the name of the certain entity, a value D2 may be for relevant data of the entity, and so on. Plus, an optional value Bl may be a numerical base value. The database 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, and so on. The dataset 110 may further have additional dataset values, as indicated by the horizontal dot-dot-dot in the right side of the dataset 110. (Each time, the dot-dot-dot suggests possibly more of what it follows.) In some embodiments, the dataset 110 has values that characterize attributes of both the primary entity 144 and the secondary entity 150, but that is not required. In some examples, the dataset 110 includes values that characterize one or more transactions. The dataset 110 may accordingly include data relating to one or more transactions. Data relating to transactions may include, but is not limited to, identification of seller, identification of buyer, product identification, service identification, price, term, and / or date.
[0043] In embodiments, digital resource rules 118 are provided for use by the OSP 154. In the example of this diagram, only one sample digital resource rule is shown explicitly, namely rule D R RULE4 122. All other such rules are indicated by the vertical dot-dot-dots. These digital resource rules 118 are digital in that they are implemented for use by software. For example, these digital resource rules 118 may be implemented within programs 106 and data 116. The data portion of these digital resource rules 118 may alternately be stored in memories that are local or in other places that can be accessed by the computer system 148. The storing can be in the form of a spreadsheet, a database, etc.0077888-00200 (AVAPAT_199)
[0044] In embodiments, the computer system 148 may access the stored digital resource rules 118. This accessing may be performed responsive to the computer system 148 receiving a dataset, such as the dataset 110.
[0045] Then the computer system 148 may select a certain one of the accessed digital resource rules 118. In this example, the rule D_R_RULE4 122 is thus selected as the certain digital resource rule. The selection of this particular rule is indicated also by the fact that an arrow 124 begins from that rule.
[0046] The computer system 148 may thus select the rule D_R_RULE4 122 responsive to one or more of the dataset values of the dataset 110. The impact of the dataset 110 in the selection is indicated by at least some of the arrows 120.
[0047] Then the computer system 148 may produce a resource for the dataset 110, such as the resource 126. The computer system 148 may thus produce the resource by applying the certain digital resource rule, which was previously selected, to at least one of the dataset values of the dataset 110. In the example of FIG. 1, the resource 126 is produced for the dataset 110 by the computer system 148 applying the certain digital resource rule D R RULE4 122, as indicated by the arrow 124. The impact of the dataset 110 in producing the resource 126 is indicated by at least one of the arrows 120.
[0048] The produced resource can be a document, a determination, a computational result, etc., made, created, or prepared for the user 142, and / or the primary entity 144, and / or the secondary7entity' 150, 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 characterized attribute of the primary entity 144 and / or the secondary entity 150. In some examples, the resource is produced on the basis of transaction data.
[0049] The resource may be produced in a number of ways. For instance, at least one of the dataset values of the dataset 110 can be a numerical base value, e.g., Bl, as mentioned above. In such cases, applying the certain digital resource rule may include performing a mathematical operation on the base value Bl. For example, applying the certain digital resource rule may include multiplying the numerical base value Bl with a number indicated by the certain digital resource rule. Such a number can be, for example, a percentage, e.g., 1.5%, 3%, 5%, and so on. Such a number can be indicated directly by the certain digital resource rule, or be stored in a place indicated by the certain digital resource rule, or by the dataset 110, and so on.
[0050] In some embodiments two or more digital main rules may be applied to produce the resource. For example, the computer system 148 may select, responsive to one or more of the0077888-00200 (AVAPAT_199) dataset values, another one of the accessed digital resource rules 118. These one or more dataset values can be the same as, or different than, the one or more dataset values responsive to which the first selected rule was selected. In such embodiments, the resource can be produced by the computer system 148 also applying the other selected digital resource rule to at least one of the dataset values. For instance, where the base value Bl is used, applying the first selected rule may include multiplying the numerical base value Bl with a first number indicated by the first selected rule, so as to compute a first product. In addition, applying the second selected rule may include multiplying the numerical base value Bl with a second number indicated by the second selected rule, so as to compute a second product. For example, a value of the resource may be produced by summing the first product and the second product.
[0051] In some examples, candidate data 158 may be determined. The candidate data 158 may be identified by the computer system 148 in some examples. The candidate data 158 maybe based on one or more of the digital resource rules 118. For example, the candidate data 158 may be data which, if included in the dataset 110, may cause one or more additional digital resource rules 118 to be used in calculating the resource 126 and / or additional resources.
[0052] In embodiments, a notification can be caused to be transmitted, e.g., via the network 134, by the computer system 148. In the example of FIG. 1, a notification 112 can be caused to be transmitted by the computer system 148, for example as an answer or other response to the received dataset 110.
[0053] The notification can be about an aspect of the resource, and possibly not about the whole resource; or the notification can be about the whole resource. For example, the notification 112 may inform about an aspect of the resource 126, namely that it has been determined, or where it can be found, or what it is, or a portion of its content, or a value of it, or a statistic of the value, or a rounded version of the value, and so on. Of course, the planning should be such that the recipient of the notification 112 understands what it is being provided. The notification 112 can be about the candidate data 158 in some examples.
[0054] The notification 112 can be transmitted to another device, such as an output device. The output device may be the screen of a local user or a remote user. The notification 112 may thus cause a desired image, message, or other such notification to appear on the screen, such as within a Graphical User Interface (GUI) and so on. The other device can be the remote device, from which the dataset 110 was received, as in the example of FIG. 1. In particular, the computer system 148 may cause the notification 112 to be communicated by being encoded as a payload 114, which is carried by a response 132. The response 132 may be0077888-00200 (AVAPAT_199) transmitted via the network 134 responsive to the received request 130. The response 132 may be transmitted to the computer system 138, or to OPF 136, and so on. As such, the other device can be the computer system 138, or the OPF 136, or the screen 140 of the user 142, and so on. In this example, the single payload 114 encodes the entire notification 112, but that is not required. Similarly with what is written above about encoding datasets in payloads, the notification 112 instead may be provided via two or more payloads, or in other cases, the notification 112 and at least one other notification may be included in the same single payload. Along with the aspect of the resource 126, it can be advantageous to embed in the payload 114 the identity value (ID) and / or one or more values of the dataset 110. This will help the recipient correlate the response 132 to the request 130, and therefore match the received aspect of the resource 126 as the answer or other response to the appropriate dataset.
[0055] As seen above, the computer system 138, the computer system 148, and possibly also the OPF 136 may exchange requests and responses. Such can be implemented with a number of different architectures. Two examples are now described with reference to the computer systems 138 and 148 only.
[0056] In one such architecture, a device remote to the service engine 128, such as the computer system 138, may have a certain application (not shown) and a connector (not shown) that may be implemented as a plugin that sits on top of that certain application. The connector may be able to fetch from the remote device the details used for the service desired from the OSP 154, form an object or payload (e.g., 108), and then send or push a request (e.g., 130) that carries the payload to the service engine 128 via a service call. The service engine 128 may receive the request with its payload. The service engine 128 may then access the digital resource rules 118, find the appropriate one(s) of them, and apply it or them to the payload to produce the requested resource 126. The service engine 128 may then form a payload (e.g., 114) that includes an aspect of the resource 126, and then push, send, or otherwise cause to be transmitted a response (e.g., 132) that carries the payload it formed to the connector. The connector receives the response, reads its payload, and forwards that payload to the certain application.
[0057] An alternative such architecture uses Representational State Transfer (REST) Application Programming Interfaces (APIs). REST or RESTful API design is designed to take advantage of existing protocols. While REST can be used over nearly any protocol, it usually takes advantage of Hyper Text Transfer Protocol (HTTP) when used for Web APIs. In such an alternative architecture, a device remote to the service engine 128, such as the computer system 138, may have a particular application (not shown). In addition, the computer system 148 implements a REST API (not shown). This alternative architecture enables the primary'0077888-00200 (AVAPAT_199) entity 144 to directly consume a REST API from their particular application, without using a connector. The particular application of the remote device may be able to fetch internally from the remote device the details used for the service desired from the OSP 154, and thus send or push the request 130 to the REST API. In turn, the REST API talks in the background to the service engine 128. Again, the service engine 128 determines the requested resource 126 and / or candidate data 158, and sends an aspect of it back to the REST API. In turn, the REST API sends the response 132 that has the payload 114 to the particular application.
[0058] Referring again to the digital resource rules 118. digital rules in embodiments can be expressed in the form of a logical “if-then” statement, such as: “if P then Q.” In such statements, the “if’ part, represented by the “P,” is called the condition, and the “then” part, represented by the “Q,” is called the consequent. In a set of digital rules, the condition or the consequent may be repeated. For instance, the condition can be the same for multiple different rules. And the consequent can be the same for multiple different rules.
[0059] Searching for a rule that applies can be performed by searching for whether or not the rule’s one or more conditions are met. The computer system may recognize that such a condition is met. For instance, the certain condition could define a boundary of a region that is within a space. The region could be geometric, and be within a larger space. The region could be geographic, within the space of a city , a state, a country', a continent, or the earth. The boundary of the region could be defined in terms of numbers according to a coordinate system within the space. In the example of geography, the boundary could be defined in terms of groups of longitude and latitude coordinates. For instance, the attribute could be a location of the entity, and the one or more values of the dataset 110 that characterize the location could be one or more numbers, or an address, or longitude and latitude. A condition can be met depending on how the one or more values compare with the boundary. For example, the comparison may reveal that the location is in the region instead of outside the region. The comparison can be made by7rendering the characterized attribute in units comparable to those of the boundary7. For example, the characterized attribute could be an address that is rendered into longitude and latitude coordinates, and so on.
[0060] In some examples, the certain condition could be an attribute of a transaction - a particular product, attribute of a product, location of the transaction, identity7of the seller or buyer, etc. A condition can be met depending on how the transaction data compare with predetermined transaction data for particular digital rules.
[0061] The search can be iterative through all the digital rules of a set of rules or of a subset of rules. Sometimes once the condition of one rule is met, its consequent is applied, and the0077888-00200 (AVAPAT_199) search effectively stops. Other times, all eligible rules are searched, and those whose conditions are met are marked for later consideration and application, for instance by proper implementation of the consequent.
[0062] The digital resource rules 118 includes the rule D R RULE4 122 that is eventually selected and applied. In some embodiments, the digital resource rules 118 are implemented by simple rules. A simple rule has a single condition (“P”), and a single consequent (“Q”). As a result of an initial search, then, the digital resource rule D_R_RULE4 122 is selected, and then its consequent is applied to produce the resource.
[0063] In some embodiments, the digital resource rules 118 further include additional digital resource rules that select that digital resource rule D_R_RULE4 122 in the first place, for ultimately applying it. In such embodiments, the digital resource rules 118 can be implemented as simple rules or as complex rules. Complex rules may have more than one condition, and / or more than one consequent. Complex rules may be implemented as individual single rules with complex coding. Alternatively, a complex rule may be implemented in part by more than one simple individual rule, which can have hierarchical relationships among them, e.g., from one rule’s application or execution leading to another, and so on. As a result of the initial search, then, rules are found which, when applied, select that certain rule in the first place.
[0064] Examples of computing systems described herein, such as the computer system 148, may identify candidate data, such as candidate data 158 of FIG. 1. The candidate data 158 may be or include data which, if included in the dataset 110, implicates additional and / or different digital resource rules 118.
[0065] FIG. 2 is a schematic illustration including example digital resource rules arranged in accordance with examples described herein. Referring now to FIG. 2, a dataset 202 can be as described for the dataset 110 of FIG. 1. In addition, a set 206 of digital resource rules is an example of digital resource rules, such as the digital resource rules 118 of FIG. 1.
[0066] Similarly with FIG. 1, in FIG. 2, a resource 204 can be produced according to an arrow 252. The resource 204 can be as the resource 126, at least an aspect of which can be reported by the notification 112. and so on. In FIG. 2. candidate data 254 can be produced. The candidate data 254 may be used to implement and / or may be implemented by the candidate data 158 of FIG. 1 in some examples.
[0067] The set 206 of digital resource rules includes different subsets, into which the individual rules belong. In addition, there are hierarchical relationships among rules of different subsets, and / or of types. One of these individual rules is eventually selected and0077888-00200 (AVAPAT_199) applied, while one or more of them may have been used for selecting it. That certain rule that is eventually selected is not pointed out in FIG. 2, as it was pointed out in FIG. 1, so as to not suggest that that certain rule necessarily belongs in any one of the subsets. In fact, that certain rule can be in any subset of the digital resource rules set 206.
[0068] In the example of FIG. 2, the set 206 includes a subset 236 of domain-selecting rules. The set 206 also includes subsets 244, 210, 208, ... , each for digital resource rules for domains A, B, C, ... , respectively. A domain for which a subset of resource rules is thus provided could be associated with the primary entity 144 of FIG. 1. another domain could be associated with the secondary entity 150, and so on. In some examples, subsets of resource rules may be provided for particular products and / or aspects of products.
[0069] In many embodiments, one of the domain-selecting rules of the subset 236 can be used to select which domain’s rules should be applied. Then the certain one of the digital resource rule(s) can be selected from the digital resource rules of the selected domain. Then the resource 204 can be produced by applying the selected certain digital resource rule(s) to at least one of the dataset values of the dataset 202.
[0070] In this example, the subset 236 of domain-selecting rules includes rules D S RULEl 238, D_S_RULE2240, D_S_RULE3 242, and further rules as indicated by the ellipsis n FIG. 2. One of these rules may be selected and used when more than one domain could be considered as eligible for its rules to apply. The rules of the subset 236, however, might not be necessary for embodiments where a single domain is considered or implied for one or more, or all, of the relationship instances. This can happen, for example, when it is known in advance that the primary entity 144 and even' possible secondary entity are both associated with the same domain. Or, when it is planned that digital resource rules of only one domain will be considered, while any rules of any other domain will not be considered and will be disregarded.
[0071] Examples of resource rules for individual domains are now described. Such rules need not be the same for each domain, or of the same type for each domain. Such rules need not be the same for each transaction, or of the same type for each transaction. The sample subset 244 of resource rules for domain A is now described in more detail. Its description can be similar for subsets for other domains, such as the subsets 210, 208, and further subsets as indicated by the ellipsis in FIG. 2.
[0072] The subset 244 of resource rules includes different types of rules. In this example, the subset 244 includes precedence rules 212, main rules 220, and override rules 228. In this example, the precedence rules 212 include rules P RULEl 214, P RULE2 216, P RULE30077888-00200 (AVAPAT_199)218, and others as indicated by the ellipsis in FIG. 2. The main rules 220 include rules M_RULE1 222, M_RULE2 224, M_RULE3 226, and others as indicated by the ellipsis in FIG. 2. The override rules 228 include rules O RULEl 230, O RULE2 232, O RULE3 234, and others as indicated by the ellipsis in FIG. 2.
[0073] In embodiments, one of the main rules 220 may ordinarily be selected as the certain digital resource rule, which in FIG. 1 is shown as rule D R RULE4 122. In other words, the certain digital resource rule could be, say, the main rule M_RULE2 224.
[0074] In this example, although not always required, the different types of rules within the subset 244 further have different hierarchies among them.
[0075] For a first instance, one of the precedence rules 212 may indicate which one of the main rules 220 is to be selected, as generally indicated by an arrow 248. Or, one of the precedence rules 212 that does apply may itself be the eventually selected certain digital resource rule, instead of indicating any one of the main rules 220.
[0076] For a second instance, even when one of the main rules 220 is thus indicated, one of the override rules 228 may still override the indication, as generally indicated by an arrow 246. In such cases, one of the override rules 228 that overrides may be the eventually selected certain digital resource rule, instead of one of the main rules 220. Or one of the override rules 228 overrides by indicating yet a different one of the main rules 220 to be selected instead, and so on.
[0077] In FIG. 2, sample arrows 250a. 250b, and 250d begin from the dataset 202. These arrows suggest possible paths of the eventual selection of the certain rule, for ultimately producing the resource 204. These arrows are more detailed versions of the arrows 120 of FIG. 1. They are examples of possible arrows, and not all of them are necessarily used in every such determination.
[0078] According to the arrow 250a, the subset 244 is indicated. So, at least one of the rules of the subset 244 may initially be indicated as the certain rule, e.g., from one or more values of the dataset 202. The initially indicated rule can be the finally certain rule, or another intermediate rule which, in turn, will be used to select that certain rule.
[0079] According to the arrow 250b, at least one of the domain-selecting rules of the subset 236 may be invoked, from one or more values of the dataset 202.
[0080] According to the arrow 250c, the one of the rules of subset 236 that was invoked by the arrow 250b was the D_S_RULE2 240. And, the arrow 250c further indicates that the invoked rule points to the subset 244, instead of to the subsets 210. 208, or others as indicated by the ellipsis in FIG. 2. As such, the subset 244 of resource rules should be used for selecting0077888-00200 (AVAPAT_199) the certain rule. This example has the same result, but from a different path, as the sample arrow 250a.
[0081] The arrow 250d is drawn to indicate that one or more of the values of the dataset 202 are received and processed by the finally selected certain rule, for producing the resource 204.
[0082] Examples of systems described herein may be used to recognize that, had additional data been present in the dataset 202, additional and / or different rules would have been selected for calculation of the resource 204 and / or other resources. For example, had additional data been present in dataset 202, D_S_RULE1 238 may have been applicable instead of or in addition to D S RULE2 240. This additional data may be identified by candidate data 254.
[0083] FIG. 3 is a schematic illustration of a system arranged in accordance with examples described herein. The example of FIG. 3 includes enterprise 302, online software platform 320, rule system 362, and customer 306. The enterprise 302 may operate computer 308. The computer 308 may be used to implement all or a portion of ERP system 358. The computer 308 may host and / or have access to enterprise data 360. The customer 306 may be a customer of the enterprise 302. The online software platform 320 may include server computer 322. The server computer 322 may include front end 324, rule system interface 330, computation engine 310, and recommendation system 338. The server computer 322 may include and / or be in communication with storage for enterprise config 336, digital rules 326, resource scenarios 332, and historical transaction data 334. The front end 324 may include connector 328 and may include storage for and / or be in communication with storage for connector config 372. The recommendation system 338 may include machine learning (ML) model 340. The recommendation system 338 may generate candidate scenario 342 and / or candidate data 344. The rule system 362 may include computer 364. The rule system 362 may be in communication with authorities, such as authority 350. During operation, the enterprise 302 may send to online software platform 320 and / or server computer 322 a request 312 which may include request data 316. The enterprise 302 may receive a response 314 including response data 318.
[0084] FIG. 3 may in some examples be used to implement and / or may be implemented by the system of FIG. 1. For example, the online software platform 320 may be used to implement and / or may be implemented by the online software platform (OSP) 154 of FIG. 1. The enterprise 302 may be used to implement and / or may be implemented by the primary entity 144 of FIG. 1. The customer 306 may be used to implement and / or may be implemented by secondary7entity 150 of FIG. 1.0077888-00200 (AVAPAT_199)
[0085] The components shown in FIG. 3 are exemplary. Additional, fewer, and / or different components may be present in other examples.
[0086] Examples of systems described herein accordingly may interact with one or more enterprise systems, such as enterprise 302 of FIG. 3. The enterprise may generally be a corporation, business, or other organization which is engaging in transactions (e.g., selling goods and / or services). The enterprise may maintain one or more computer systems, such as computer 308 of FIG. 3. Computers operated by enterprises interacting with the online software platforms described herein may be referred to as client systems. Accordingly, the computer 308 and / or ERP system 358 may be referred to as client systems in some examples. The computer systems of the enterprise may include one or more processors and computer readable media (e.g., memory or other electronic storage) which may be encoded with executable instructions for performing operations described herein. For example, computer systems of the enterprise may include one or more ERP systems, such as ERP system 358 of FIG. 3. The ERP system 358 may be implemented using the computer 308. Generally, ERP systems refer to one or more software applications that may manage and / or integrate business processes. Examples of business processes which may be managed by ERP system 358 of FIG. 3 include, but are not limited to, finance, human resources, supply chain management, manufacturing, invoicing, and / or customer relationship management processes. Accordingly, enterprises described herein may generate, store, and / or access enterprise data, such as enterprise data 360 in FIG. 3. The enterprise data 360 may be stored on any computer readable media integrated with and / or in communication with the ERP system 358. The enterprise data 360 may include, for example, pricing data, product data, transaction data, invoicing data, customer data, and / or other data relating to the enterprise 302, customers of the enterprise 302, products and / or services offered by the enterprise 302, and / or transactions conducted by the enterprise 302. While a single enterprise 302 is depicted in FIG. 3, any number of enterprises may be present in examples described herein, and multiple enterprises may be in communication with OSPs described herein. Enterprises may have one or more customers, such as customer 306 of FIG. 3. The customer may be an individual human and / or another computer system (e g., software process). The customer may conduct transactions with the enterprise 302. For example, the customer 306 may purchase one or more goods or services from the enterprise 302. Data relating to the transactions may be managed by ERP system 358 and stored in enterprise data 360.
[0087] Examples of systems described herein may include one or more rule systems, such as rule system 362 of FIG. 3. The rule system 362 may be implemented using one or more computer systems, such as computer 364 of FIG. 3. The computer 364 of FIG. 3 may include0077888-00200 (AVAPAT_199) one or more processors and computer readable media encoded with executable instructions for performing operations described herein. The rule system 362 may be in communication with one or more authorities or other entities, such as authority' 350 of FIG. 3. In some examples, the authority 350 may be, for example, a governmental entity, such as a federal government, state government, local government, and / or other entity which may set rules for resource obligations, such as tax or fee obligations relating to transactions. The authority 350 may itself have one or more computer systems. Accordingly, the computer 364 may communicate with one or more computer systems of various authorities to develop digital rules described herein, such as digital resource rules 118 of FIG. 1 and / or digital resource rules 206 of FIG. 2. In some examples, an expert or other user of the rule system 362 may synthesize, format, store, or otherwise arrange the digital resource rules for use by the online software platform 320.
[0088] Examples of systems described herein may include online software platforms, such as online software platform 320 of FIG. 3. While examples may be implemented using an online software platform, other examples may not utilize an online software platform. Examples of systems described herein, including examples using online software platforms, may include one or more computing systems, such as server computer 322. The server computer 322 may include one or more processors and computer readable media (e.g., memory or other electronic storage) encoded with instructions which, when executed by the processor, cause the computer to perform operations described herein. Any number of processors and computer readable media may be present. The computer readable media may be integral to and / or in communication with the server computer 322.
[0089] Examples of OSPs and / or computers described herein may include a computation engine, such as computation engine 310 of FIG. 3. The computation engine 310 may be implemented using one or more processors and computer readable media encoded with executable instructions for performing operations described herein. The computation engine 310 may generally perform computations, such as computations of one or more resources in accordance with one or more digital rules. The computation engine 310 in some examples may perform comparisons, such as comparisons between transaction data and historical transaction data described herein. The computation engine 310 in some examples may analyze a degree of coherence between datasets. Generally, coherence can be used to sense missing information on a transaction that if provided, will result in more or different resource calculations. Sensing the missing information based on coherence with other available information may enhance the accuracy of that determination. Data coherence generally refers to uniformity across shared resource data. Data coherence may further refer to logical0077888-00200 (AVAPAT_199) connections and completeness within a single data set and across data sets. Examples of a coherence calculation and / or analysis include a combination of tax types and transaction data and other applicable tax liabilities. Systems described herein may evaluate a degree to which certain transaction parameters and / or tax types belong together.
[0090] Examples of OSPs and / or computers described herein may include an interfacefor a rule system, such as rule system interface 330 of FIG. 3. The interface may be implemented using a software component (e.g., a plugin, application, or other software). Accordingly, rule system interface 330 may be implemented using one or more processors (e.g., one or more processors of server computer 322 and computer readable media encoded with instructions for performing rule system interface operations described herein). The rule system interface 330 may obtain information from rule system 362 and / or other rule systems in communication with server computer 322 and / or online software platform 320. The rule system interface 330 may accordingly receive new and / or updated digital rules, and may store the rules in storage accessible to the online software platform 320 and / or server computer 322. The rule system interface 330 may generally translate one or more resource rules into one or more digital rules which may be stored in storage. In some examples, the rule system interface 330 may receive input from one or more computer systems, which may for example, be utilized by a researcher that may create digital versions of resource rules and transmit or otherwise provide the digital resource rules to the online software platform 320 and / or server computer 322.
[0091] For example, the rule system interface 330 may store digital rules in digital rules 326. The digital rules 326 may be implemented using computer readable media (e.g., memory or storage such as one or more disk drives, network storage, cloud storage, solid state drives). The computation engine 310 may in some examples group and / or organize the digital rules into resource scenarios 332. The resource scenarios 332 may be implemented using computer readable media (e.g., memory or storage such as one or more disk drives, network storage, cloud storage, solid state drives). The resource scenarios 332 may group digital rules into particular groups, also called scenarios. The resource scenarios 332 may include data which specifies, for particular transaction data, which digital rules are applicable for the calculation of resource obligations arising from the transaction data. The resource scenarios may be particular to a transaction place, time, buyer location, seller location, product, and / or other attributes of a transaction. During operation, the computation engine 310 may select one or more resource scenarios 332 for use in calculating resources arising from a transaction.
[0092] Examples of online software platforms and / or computers described herein may include historical transaction data, such as historical transaction data 334 of FIG. 3. The historical transaction data 334 may be implemented using data stored in computer readable0077888-00200 (AVAPAT_199) media (e.g., memory or storage such as one or more disk drives, network storage, cloud storage, solid state drives). The historical transaction data 334 may include data relating to transactions previously performed by enterprise 302 and / or other entities or enterprises utilizing server computer 322 and / or online software platform 320. The historical transaction data 334 may include data relating to resource obligations calculated by server computer 322 and / or online software platform 320 as a result of transactions. In this manner, over time, the online software platform 320 and / or server computer 322 may build up a repository7of data regarding transactions for products and services and the associated resource obligations arising from those transactions. The computation engine 310 may store the historical transaction data in historical transaction data 334.
[0093] Examples of online software platforms and / or computers described herein may include enterprise configuration information, such as enterprise config 336 of FIG. 3. The enterprise config 336 may be implemented using data stored in computer readable media (e.g., memory or storage such as one or more disk drives, network storage, cloud storage, solid state drives). The enterprise configuration information may include information relating to one or more entities, such as enterprise 302 in the example of FIG. 3. Examples of enterprise configuration information include entity name, location, products offered, services offered, customers, authorizations (e.g., authorization for server computer 322 and / or online software platform 320 to access data of ERP system 358 and / or perform particular calculations).
[0094] Examples of online software platforms and / or computers described herein may include a front end, such as front end 324. The front end 324 may include a connector, such as connector 328. The connector 328 may connect to computer systems at one or more entities, such as computer 308 and / or ERP system 358 of FIG. 3. The front end 324 and / or connector 328 may be implemented using one or more plug-ins, applications, APIs, or other interfaces. The front end 324 and / or connector 328 may be implemented using one or more processors and executable instructions encoded on computer readable media. The front end 324 may include connector configuration information, such as connector config 372. The connector configuration information may be implemented using data stored in computer readable media (e.g.. memory or storage such as one or more disk drives, network storage, cloud storage, solid state drives). The connector configuration information may specify particular information to receive from entities in communication with the server computer 322. For example, the connector config 372 may specify particular data to obtain from the ERP system 358 and / or particular portions of the ERP system 358 for access by the server computer 322 and / or connector 328.0077888-00200 (AVAPAT_199)
[0095] Examples of online software platforms and / or computers described herein may include a recommendation system, such as recommendation system 338 of FIG. 3. The recommendation system 338 may be implemented using one or more processors and / or computer readable media encoded with instructions to perform operations described herein. The recommendation system 338 may receive transaction data, such as data from ERP system 358. The transaction data may be received at the recommendation system 338 through front end 324, connector 328, and / or computation engine 310. The recommendation system 338 may compare the transaction data with historical transaction data, such as historical transaction data 334. The comparison may result in the recommendation system 338 recommending a candidate scenario 342 and / or candidate data 344. The candidate data 344 may be data which has a degree of coherence with historical transaction data in the historical transaction data 334. For example, the candidate data 344 may be data which, if included in the transaction data received from ERP system 358, may be expected to result in additional resource obligations arising from the transaction. The candidate scenario 342 may be a resource scenario which may be expected to apply if the candidate data 344 were included with the transaction data. The candidate scenario 342 may be selected by the recommendation system 338 from the resource scenarios 332.
[0096] During operation, the online software platform 320 of FIG. 3, including server computer 322, may be used to make resource calculations for one or more enterprises, such as enterprise 302. Generally, enterprise 302 may provide transaction data to server computer 322 using ERP system 358. For example, an invoicing system of ERP system 358 may provide invoicing data to server computer 322, such as to connector 328. The transaction data and / or a request to calculate resource obligations arising from the transaction data may be provided as request 312 including request data 316. The computation engine 310 may receive the transaction data, select one or more resource scenarios from resource scenarios 332 having a set of digital rules from digital rules 326. The digital rules for the resource scenario may be used to calculate resource obligations (e.g., taxes and fees) arising from the transaction. The calculated resource may be returned to computer 308 and / or ERP system 358 as response data 318 with response 314.
[0097] However, in some examples, the transaction data provided to the online software platform 320 and / or server computer 322 may be incomplete. For example, it may be an invoicing system of the ERP system 358 which provides transaction data to the server computer 322. The transaction data may accordingly be implemented using data found on invoices provided to one or more customers, such as customer 306. The invoice may show resources charged to the customer, but may not show other resources expended by the0077888-00200 (AVAPAT_199) enterprise 302. The invoice may show some information about the product or service offered to the customer 306 in the transaction, but may not include all information available about the product or service. Because of this lack of information, the online software platform 320 and / or server computer 322 may not calculate all applicable resource obligations arising from the transaction. However, by examining the coherence of the transaction data with historical transaction data from the same and / or from other enterprises, the server computer 322 may identify additional data which may be used to calculate and / or refine resource calculations arising from the transaction. In this manner, recommendation system 338 may generate candidate data 344 and / or candidate scenario 342. The candidate data 344 and / or candidate scenario 342 may be provided to computer 308 and / or ERP system 358 as request data 316 with response 314.
[0098] In some examples, the candidate data may be provided by the computer 308 and / or ERP system 358 in a further request 312. The additional candidate data may be used by computation engine 310 to calculate additional resource obligations and / or update resource calculations. The additional resource obligations and / or updated resource calculations may be provided to computer 308 and / or ERP system 358 as response data 318 with response 314.
[0099] FIG. 4 is a schematic illustration of a computer system arranged in accordance with examples described herein. FIG. 4 includes a sample computer system 414 and a sample computer system 412. The computer system 414 may be a server, while the computer system 412 may be a personal computing device, such as a personal computer, a desktop computer, a laptop computer, a tablet computer, a mobile phone, and so on. Any type may be used for the computer system 148 and computer system 138 of FIG. 1, and / or a computer system that is part of OPF 136.
[0100] Further, either computer system 414 and / or computer system 412 may be used to implement server computer 322, computer 364, and / or computer 308 of FIG. 3.
[0101] The computer system 414 and the computer system 412 have similarities, which FIG. 4 exploits for purposes of economy in this document. It will be understood, however, that a component in the computer system 414 may be implemented differently than the same component in the computer system 412. For instance, a memory in a server may be larger than a memory in a personal computer, and so on. Similarly, custom application programs 442 that implement embodiments may be different, and so on.
[0102] The computer system 414 includes one or more processor(s) 416. The processor(s) 416 are one or more physical circuits that manipulate physical quantities representing data values. The manipulation can be according to control signals, which can be known as0077888-00200 (AVAPAT_199) commands, op codes, machine code, etc. The manipulation can produce corresponding output signals that are applied to operate a machine. As such, one or more processor(s) 416 may, for example, include a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), a Field-Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), any combination of these, and so on. A processor may further be a multi-core processor having two or more independent processors that execute instructions. Such independent processors are sometimes called “cores.”
[0103] A hardware component such as a processor may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. For example, a hardware component may include software executed by a general-purpose processor or another type of programmable processor. Once configured by such software, hardware components become specific machines, or specific components of a machine, uniquely tailored to perform the configured functions and are no longer general-purpose processors. It will be appreciated that the decision to implement a hardware component mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software), may be driven by cost and time considerations.
[0104] As used herein, a “component” may refer to a device, physical entity, or logic having boundaries defined by function or subroutine calls, branch points. Application Programming Interfaces (APIs), or other technologies that provide for the partitioning or modularization of particular processing or control functions. Components may be combined via their interfaces with other components to carry out a machine process. A component may be a packaged functional hardware unit designed for use with other components and a part of a program that usually performs a particular function of related functions. Components may constitute either software components (e.g., code embodied on a machine-readable medium) or hardware components. The hardware components depicted in the computer system 414, or the computer system 412, are not intended to be exhaustive. Rather, they are representative, for highlighting essential components that can be used with embodiments.
[0105] The computer system 414 also includes a system bus 456 that is coupled to the processor(s) 416. The system bus 456 can be used by the processor(s) 416 to control and / or communicate with other components of the computer system 414.
[0106] The computer system 414 additionally includes a network interface 418 that is coupled to system bus 456. Network interface 418 can be used to access a communications0077888-00200 (AVAPAT_199) network, such as the network 134. Network interface 418 can be implemented by a hardware network interface, such as a Network Interface Card (NIC), wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components such as Bluetooth® Low Energy, Wi-Fi® components, etc. Of course, such a hardware network interface may have its own software, and so on.
[0107] The computer system 414 also includes various memory' components. These memory components include memory components shown separately in the computer system 414, plus cache memory’ within the processor(s) 416. Accordingly, these memory components are examples of non-transitory machine-readable media. The memory components shown separately in the computer system 414 are variously coupled, directly or indirectly, with the processor(s) 416. The coupling in this example is via the system bus 456.
[0108] Instructions for performing any of the methods or functions described in this document may be stored, completely or partially, within the memory components of the computer system 414, etc. Therefore, one or more of these non-transitory computer-readable media can be configured to store instructions which, when executed by one or more processor(s) 416 of a host computer system such as the computer system 414 or the computer system 412, can be designed to or programmed to cause the host computer system to perform operations according to embodiments. The instructions may be implemented by computer program code for carrying out operations described herein. The computer program code may be written in any combination of one or more programming languages, including an object- oriented programming language such as Java, Smalltalk, or the like, and / or conventional procedural programming languages, such as the “C” programming language or similar programming languages such as C++, C Sharp, etc.
[0109] The memory components of the computer system 414 include a non-volatile hard drive 422. The computer system 414 further includes a hard drive interface 420 that is coupled to the hard drive 422 and to the system bus 456.
[0110] The memory components of the computer system 414 include a system memory 424. The system memor 424 includes volatile memory including, but not limited to, cache memory, registers, and buffers. In embodiments, data from the hard drive 422 populates registers of the volatile memory of the system memory 424.
[0111] In some embodiments, the system memory’ 424 has a software architecture that uses a stack of layers, with each layer providing a particular functionality. In this example the layers include, starting from the bottom, a (OS) Operating System 436, libraries 440, frameworks / middleware 446, and application programs 426, which are also known more2f>0077888-00200 (AVAPAT_199) simply as applications 426. Other software architectures may include fewer, more, or different layers. For example, a presentation layer may also be included. For another example, some mobile or special purpose operating systems may not provide a frameworks / middleware 446.
[0112] The (OS) Operating System 436 may manage hardware resources and provide common services. The libraries 440 provide a common infrastructure that is used by the applications 426 and / or other components and / or layers. The libraries 440 provide functionality that allows other software components to perform tasks more easily than if they interfaced directly with the specific underlying functionality of the (OS) Operating System 436. The libraries 440 may include system libraries 448, such as a C standard library. The system libraries 448 may provide functions such as memory allocation functions, string manipulation functions, mathematical functions, and the like.
[0113] In addition, the libraries 440 may include API libraries 450 and other libraries 438. The API libraries 450 may include media libraries, such as libraries to support presentation and manipulation of various media formats such as MPREG4, H.264, MP3, AAC, AMR, JPG, and PNG. The API libraries 450 may also include graphics libraries, for instance an OpenGL framework that may be used to render 2D and 3D in a graphic content on the screen 404. The API libraries 450 may further include database libraries, for instance SQLite, which may support various relational database functions. The API libraries 450 may additionally include web libraries, for instance WebKit, which may support web browsing functionality, and also libraries for applications 426.
[0114] The frameworks / middleware 446 may provide a higher-level common infrastructure that may be used by the applications 426 and / or other software components / modules. For example, the frameworks / middleware 446 may provide various GUI functions, high-level resource management, high-level location services, and so forth. The frameworks / middleware 446 may provide a broad spectrum of other APIs that may be used by the applications 426 and / or other software components / modules, some of which may be specific to the (OS) Operating System 436 or to a platform.
[0115] The application programs 426 are also known more simply as applications and apps. One such app is a browser 444, which is a software that can permit the user 452 to access other devices on the internet, for example while using a GUI. The browser 444 includes program modules and instructions that enable the computer system 414 to exchange network messages with a network, for example using Hypertext Transfer Protocol (HTTP) messaging.
[0116] The application programs 426 may include one or more custom application programs442, made according to embodiments. These can be made so as to cause their host computer0077888-00200 (AVAPAT_199) to perform operations according to embodiments. Of course, when implemented by software, operations according to embodiments may be implemented much faster than may be implemented by a human mind; for example, tens or hundreds of such operations may be performed per second according to embodiments, which is much faster than a human mind can do.
[0117] Other such applications 426 may include a contacts application, a book reader application, a location application, a media application, a messaging application, and so on. Applications 426 may be developed using the ANDROID™ or IOS™ Software Development Kit (SDK) by an entity other than the vendor of the particular platform, and may be mobile software running on a mobile operating system. The applications 426 may use built-in functions of the (OS) Operating System 436, of the libraries 440, and of the frameworks / middleware 446 to create Uis for the user 452 to interact with.
[0118] The computer system 414 moreover includes a bus bridge 428 coupled to the system bus 456. The computer system 414 furthermore includes an input / output I / O bus 454 coupled to the bus bridge 428. The computer system 414 also includes an I / O interface 430 coupled to the I / O bus 454.
[0119] For being accessed, the computer system 414 also includes one or more Universal Serial Bus (USB) ports 432. These can be coupled to the I / O interface 430. The computer system 414 further includes a media tray 434, which may include storage devices such as compact disc read-only memory (CD-ROM) drives, multi-media interfaces, and so on.
[0120] The computer system 412 may include many components similar to those of the computer system 414, as seen in FIG. 4. In addition, a number of the application programs 426 may be more suitable for the computer system 412 than for the computer system 414.
[0121] The computer system 412 further includes peripheral input / output (I / O) devices for being accessed by a user more routinely. As such, the computer system 412 includes a screen 404 and a video adapter 402 to drive and / or support the screen 404. The video adapter 402 is coupled to the system bus 456.
[0122] The computer system 412 also includes a keyboard 406, a mouse 408, and a printer 410. In this example, the keyboard 406, the mouse 408, and the printer 410 are directly coupled to the I / O interface 430. Sometimes this coupling is via the USB ports 432.
[0123] In this context, “machine-readable medium” or “computer readable media” refers to a component, device, or other tangible media able to store instructions and data temporarily or permanently and may include, but is not be limited to, a portable computer diskette, a thumb drive, a hard disk, random-access memory (RAM), read-only memory (ROM), buffer0077888-00200 (AVAPAT_199) memory, flash memory, optical media, magnetic media, cache memory, an Erasable Programmable Read-Only Memory (EPROM), an optical fiber, a portable CD-ROM, an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The machine that would read such a medium includes one or more processor(s) 416.
[0124] The term “machine-readable medium’’ or “computer readable media” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions that a machine such as a processor can store, erase, or read. The term “machine-readable medium” shall also be taken to include any medium, or combination of multiple media, that is capable of storing instructions (e.g., code) for execution by a machine, such that the instructions, when executed by one or more processors of the machine, cause the machine to perform any one or more of the methods described herein. Accordingly, instructions transform a general, non-programmed machine into a particular machine programmed to carry out the described and illustrated functions in the manner described.
[0125] A computer readable signal traveling from, to, and via these components may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
[0126] FIG. 5 is a flowchart illustrating an example method arranged in accordance with examples described herein. Block 502 recites “receive transaction data for an entity.” Block 514 may follow block 502. Block 514 recites “select resource scenario.” Block 516 may follow block 514. Block 516 recites “calculate resource obligations associated with the transaction data.” Block 504 may follow block 502. Block 504 recites “compare the transaction data with historical transaction data associated with additional entities.” Block 506 may follow block 504. Block 506 recites “identify candidate data associated with the transaction data, wherein the candidate data causes at least one additional resource obligation.” Block 508 may follow block 506. Block 508 recites “search for authorization to obtain the candidate data.” Block 510 may follow block 508. Block 510 recites “query a client system for the candidate data.” Block 512 may follow block 510. Block 512 recites “receive candidate data.” Block 514 may additionally follow block 512 in an iterative configuration.0077888-00200 (AVAPAT_199)Block 514 recites "‘select resource scenario.” Block 518 may optionally follow block 516.Block 518 recites ’‘receive feedback.”
[0127] The method of FIG. 5 may be performed by systems described herein, such as the online software platform 320 and / or server computer 322 of FIG. 3. or the online software platform (OSP) 154 and / or computer system 148 of FIG. 1. For example, the server computer 322 and / or the computer system 148 may include or access computer readable media encoded with instructions which, when executed by one or more processors of the server computer 322 and / or computer system 148, cause the system to perform the operations described with reference to FIG. 5.
[0128] The blocks shown in FIG. 5 are exemplary. Additional, fewer, and / or different blocks may be used in other examples. The blocks may be performed in a different order, or some blocks may be performed in part simultaneously in some examples. For example, although block 516 and optional block 518 are depicted as occurring in parallel with block 504, block 506, block 508, block 510, and / or block 512, in some examples, block 516 may occur sequentially, with block 504 following block 516.
[0129] Accordingly, transaction data may be received in accordance with methods described herein, such as in block 502 of FIG. 5. The transaction data may include any of a variety of information regarding one or more transactions - date, time, price, seller location, buyer location, jurisdiction, tax amounts, fee amounts, buyer identification, seller identification, product identification, and / or service identification. The transaction data may be transaction data for an entity7. For example, the transaction data may be received from an entity, such as from enterprise 302 of FIG. 3. In some examples, transaction data may be provided to an online software platform or other computing system from an ERP system, such as ERP system 358 of FIG. 3. In some examples, an invoicing system may provide transaction data. Accordingly, the transaction data may be or include one or more invoices. Referring to FIG. 3. in block 502, ERP system 358 may provide transaction data to server computer 322. The transaction data may be stored in enterprise data 360, and may include data relating to a transaction with customer 306.
[0130] A resource scenario may be selected in accordance with methods described herein, such as in block 514 of FIG. 5. For example, the transaction data may be received through front end 324 of FIG. 3. The computation engine 310 of FIG. 3 may access the transaction data and may select a resource scenario, such as by selecting a resource scenario from resource scenarios 332. In some examples, the computation engine 310 may select multiple resource scenarios. The computation engine 310 may select the resource scenario based on the0077888-00200 (AVAPAT_199) transaction data. For example, the resource scenario may be selected based on a jurisdiction and product specified in the transaction data. Other aspects of the transaction data may be used to select the resource scenario in other examples. Recall the resource scenario specifies one or more digital rules.
[0131] Resource obligations may be calculated in accordance with methods described herein, such as in block 516 of FIG. 5. The computation engine 310 of FIG. 3 may utilize the selected resource scenario or scenarios to calculate resource obligations associated with the transaction data. For example, the computation engine 310 may evaluate the digital rules specified by the resource scenario. Evaluating the digital rules may include using some or all of the transaction data. In this manner, the computation engine 310 may calculate one or more resource obligations. The resource obligations may be communicated to another computing system. For example, the resource obligations calculated in block 516 may be provided to computer 308 of FIG. 3 as response data 318 included in response 314. The resource obligations calculated in block 516 may be the resource 126 of FIG. 1 and / or resource 204 of FIG. 2 in some examples.
[0132] Examples of methods described herein may compare transaction data with historical transaction data, such as in block 504 of FIG. 5. Block 504 may be performed before, during, and / or after block 514 in some examples. Block 504 may be performed before, during, and / or after block 516 in some examples. The computation engine 310 of FIG. 3 may compare the received transaction data with some or all of historical transaction data 334. Generally, the received transaction data may be from a particular entity (e.g., enterprise 302 of FIG. 3) while the historical transaction data 334 may include transaction data from other entities (e.g., other enterprises). In this manner, the computation engine 310 may evaluate the data coherence between the received transaction data and historical transaction data. In some examples, the computation engine 310 may perform block 504 together with recommendation system 338 of FIG. 3. In some examples, the recommendation system 338 of FIG. 3 may perform block 504. For example, the computation engine 310 and / or recommendation system 338 may calculate a degree of coherence (e.g., a degree of similarity) between received transaction data and instances of transaction data in the historical transaction data 334. In some examples, a numerical value of similarity (e.g., a score) may be calculated by the computation engine 310 and / or recommendation system 338 for the received transaction data compared with other transaction data stored in historical transaction data 334.
[0133] Examples of methods described herein may identify candidate data associated with transaction data, such as in block 506 of FIG. 5. The candidate data identified may be data that, if present in the transaction data, may cause at least one additional resource obligation0077888-00200 (AVAPAT_199) to apply to the transaction data. The candidate data may be identified based on the comparison in block 504. For example, the computation engine 310 and / or recommendation system 338 of FIG. 3 may analyze historical transaction data instances which are similar to the received transaction data. The historical transaction data instances having a similarity score greater than a threshold may be analyzed. The data contained in the received transaction data may be compared with the data contained in the identified historical transaction data instances. The similar historical transaction data instances may have additional data present. The additional data may be identified as candidate data. In some examples, the historical transaction data 334 may include historical resource obligations and / or historical resource scenarios for each instance of historical transaction data. The computation engine 310 and / or recommendation system 338 of FIG. 3 may compare the resource obligations calculated in block 516 with those calculated historically for similar transaction data as stored in historical transaction data 334. Candidate data may be identified which, when present in a historical transaction data instance similar to the received transaction data, caused additional resource obligations to be calculated. In this manner, candidate data may be identified. The candidate data may be the candidate data 158 of FIG. 1, candidate data 254 of FIG. 2, and / or candidate data 344 of FIG. 3.
[0134] In some examples, machine learning techniques are used to perform the comparison and / or identification in block 504 and block 506. For example, the ML model 340 of FIG. 3 may be used to perform block 504 and / or block 506. The ML model 340 is trained in some examples to output transaction scenario(s) and / or candidate data based on input transaction data. For example, the ML model 340 may be trained on some or all of the historical transaction data 334. The ML model 340 may be trained using supervised learning, unsupervised learning, or reinforcement learning in some examples. The ML model 340 may be implemented using a set of weights which may be used in a neural network to provide output candidate data and / or resource scenarios based on input transaction data.
[0135] Examples of methods described herein may search for authorization to obtain candidate data, such as in block 508 of FIG. 5. For example, the computation engine 310 of FIG. 3 may access enterprise config 336 to determine whether a particular enterprise has authorized the computation engine 310 and / or online software platform 320 to obtain candidate data once identified. For example, UIs may be provided by systems described herein, such as online software platform 320, to prompt enterprises to provide authorization for the identification and / or request of candidate data. For example, the online software platform 320 may provide a UI for enterprise 302, such as using computer 308, and may provide authorization to request and / or obtain additional candidate data from ERP system0077888-00200 (AVAPAT_199)358. In some examples, the authorization may be provided if the online software platform 320 determines such candidate data may result in additional or revised resource obligations. The authorization may be stored in enterprise config 336 and / or other storage described herein.
[0136] Examples of methods described herein may include querying a system for candidate data such as in block 510 of FIG. 5. The online software platform 320 and / or server computer 322 may query a client system for the candidate data. For example, the computation engine 310 may, through the front end 324, send a request to the enterprise 302 (e.g., to computer 308 and / or ERP system 358) to obtain the candidate data. For example, values of data for the transaction for a class or category of data identified by the candidate data may be requested. Recall that transaction data has been provided from the ERP system to the online software platform. The online software platform may now have identified a particular kind of data that is likely to generate different or additional resource obligations - candidate data. This candidate data may be, for example, a particular attribute of a buyer, seller, jurisdiction, product, service, or other component of the transaction.
[0137] In some examples, the client system may be queried for the candidate data byupdating the configuration of a connector used to receive data from the client system. For example, the recommendation system 338 and / or computation engine 310 may update the connector config 372 to obtain the candidate data.
[0138] In examples of methods described herein, candidate data may be received, such as in block 512 of FIG. 5. The enterprise 302 of FIG. 3 may provide the candidate data to online software platform 320 (e.g., through front end 324). The ERP system 358 may provide the candidate data to the online software platform 320 in some examples. The candidate data maybe used, together with the previously-provided transaction data, to again select a resource scenario, such as in block 514 of FIG. 5. Now that the additional candidate data is available to the online software platform 320 (e.g., to computation engine 310), a different and / or additional resource scenario may be selected in block 514. Accordingly, different and / or additional resource obligations may be calculated in block 516.
[0139] In some examples of methods described herein, systems may receive feedback, such as in block 518 in FIG. 5. For example, feedback may be provided regarding whether the candidate data did in fact result in different and / or additional resource obligations. For example, the computation engine 310 of FIG. 3 may calculate additional and / or changed resource obligations in block 516 after receiving candidate data. The computation engine 310 may provide feedback to recommendation system 338 (e.g., to ML model 340) indicative of whether the resource obligations calculated with the candidate data changed from those0077888-00200 (AVAPAT_199) calculated without the candidate data. This may further refine ML model 340 in some examples, and / or further refine the comparison of transaction data to historical transaction data performed by the computation engine 310 and / or recommendation system 338.
[0140] In some examples, feedback may be provided regarding whether the different and / or additional resource obligations was appropriate. For example, the enterprise 302 may receive the additional and / or changed resource obligations. If these updated calculations were advantageous, the enterprise 302 may provide feedback to the online software platform 320. For example, the computer 308 may provide feedback to online software platform 320 through front end 324. The feedback may be used to further refine ML model 340 in some examples, and / or further refine the comparison of transaction data to historical transaction data performed by the computation engine 310 and / or recommendation system 338.
[0141] FIG. 6 is a schematic illustration of a system arranged in accordance with examples described herein. FIG. 6 is a diagram for an operational example where a buy-sell transaction 646 is a use case of the relationship instance 152. The buy-sell transaction 646 is conducted between a primary entity 638, which is a seller, and a secondary entity 644, which is a buyer. A tax obligation 622 often arises from the buy-sell transaction 646 - in particular, a sales and / or use tax is to be paid by either the primary entity 638 or the secondary entity 644. A computation of the tax obligation 622 is a use case of producing the resource 126 of FIG. 1.
[0142] It will be recognized that aspects of FIG. 6 have similarities with aspects of FIG. 1. Portions of such aspects may be implemented as described for analogous aspects of FIG. 1. In particular, a thick horizontal line 602 separates FIG. 6, although not completely or rigorously, into a top portion and a bottom portion. Above the line 602 are shown elements with emphasis mostly on entities, components, their relationships, and their interactions, while below the line 602 are shown elements with emphasis mostly on processing of data that takes place often within one or more of the components that are above the line 602.
[0143] Above the line 602, a computer system 642 is shown, which is used to help customers, such as a user 636, with tax compliance. For instance, the user 636 may log into the computer system 642 by using credentials, such as a user name, a password, a token, and so on. Further in this example, the computer system 642 is part of a (OSP) online software platform 648 that is implemented as a SaaS provider, for being accessed by the user 636 online. As such, the (OSP) online software platform 648 can be an online software provider for clients. Alternately, the functionality' of the computer system 642 may be provided locally to a user.0077888-00200 (AVAPAT_199)
[0144] The user 636 may be standalone. The user 636 may use a computer system 632 that has a screen 634. In embodiments, the user 636 and the computer system 632 are considered part of the primary' entity 638, which is also known as entity 638. The primary' entity 638 can be a business, such as a seller of items, a reseller, a buyer, a service business, and so on. In such instances, the user 636 can be an employee, a contractor, or otherwise an agent of the entity 638. In use cases the entity 638 is a seller, the secondary entity 644 is a buyer, and together they are performing the buy-sell transaction 646. The buy-sell transaction 646 may involve an operation, such as an exchange of data to form an agreement. The buy-sell transaction 646 may involve the sale of a product and / or service. This operation can be performed in person, or over the network 134 of FIG. 1, etc. In such cases the entity 638 can even be an online seller, but that is not necessary. The buy -sell transaction 646 will have data that is known to the entity 638, similarly with what was described by the relationship instance 152 of FIG. 1.
[0145] In a number of instances, the user 636 and / or the entity' 638 use software applications to manage their business activities, such as sales, resource management, production, inventory' management, delivery, billing, and so on. The user 636 and / or the entity 638 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 636, or from an Online Processing Facility (OPF) 630 that has been engaged for this purpose by the user 636 and / or the entity 638. In such use cases, the OPF 630 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. For example, the ERP system 358 may be used in some examples.
[0146] Businesses have tax obligations to various tax authorities of respective tax jurisdictions. These tax obligations are challenging. A first challenge is in making the related determinations. Tax-related determinations, made for the ultimate purpose of tax compliance, are challenging 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, and many more. 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.0077888-00200 (AVAPAT_199)
[0147] 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, of a 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 money owed to the tax authority as sales tax because of 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.
[0148] A challenge for businesses is that the above-mentioned 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 generally not good to have such errors. For example, businesses that sell products and services have risks whether they over-estimate or under-estimate the sales tax due from a sale transaction. On the one hand, if a seller over-estimates 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 is to 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 under-estimates 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 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.0077888-00200 (AVAPAT_199)
[0149] For sales in particular, making correct determinations for sales and use tax is even more difficult. There are a number of factors that contribute to its complexity.
[0150] 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 authority of the seller, or from the buyer’s location, meaning according to the rules of the tax authority of the buyer.
[0151] 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 jurisdictions in the United States, 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.
[0152] Third, in some instances no sales tax is due at all because of the type of item sold. For example, in 2018, selling 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.
[0153] 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.
[0154] 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 be0077888-00200 (AVAPAT_199)"‘engaged in business7’ with it, and therefore that business is subject to registration and collection of sales taxes. These nexus rules may include different types of nexuses, such as affiliate 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.
[0155] 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.
[0156] Moreover, it can be hard to determine what data will be needed or used by the online software platform in calculating the tax. Without a full understanding of all applicable tax laws in all applicable jurisdictions or territories, it may be difficult to determine what data to provide to the online software platform to calculate tax obligations. For example, for alcoholic products, different tax obligations may apply in certain jurisdictions based on the alcohol content of the product. However, the seller and / or seller’s ERP system may not be setup to regularly send alcohol content of products to the online software platform. In examples where invoices are provided to the online software platform, the invoices may not contain all of the information which could be used by the online software platform to select resource scenarios and / or to calculate tax obligations.
[0157] To help with such complex determinations, the computer system 642 may be specialized for tax compliance. The computer system 642 may have one or more processors and memory, for example as was described for the computer system 148 of FIG. 1. The computer system 642 thus implements a tax engine 640 to make the determinations of tax obligations. The tax engine 640 can be as described for the service engine 128.
[0158] The computer system 642 may further store locally entity data, e.g., data of user 636 and / or of entity 638, either of which / whom may be a customer, and / or a seller or a buyer in a sales transaction. The entity data may include profile data of the customer, and transaction data from which a determination of a tax obligation is desired. In the online implementation of FIG. 6, the (OSP) online software platform 648 has a database 652 for storing the entity data. This entity data may be inputted by the user 636, and / or caused to be downloaded or0077888-00200 (AVAPAT_199) uploaded by the user 636 from the computer system 632 or from the OPF 630, or extracted from the computer system 632 or from OPF 630, and so on. In other implementations, a simpler memory configuration may suffice for storing the entity data.
[0159] A digital tax content 604 is further implemented within the (OSP) online software platform 648. The digital tax content 604 can be a utility that stores digital tax rules 614 for use by the tax engine 640. As part of managing the digital tax content 604, there may be periodic and / or continuous updates of the digital tax rules, by inputs gleaned from a set 654 of different tax authorities 656, 658, etc. Updating may be performed by humans and / or by computers. As mentioned above, the number of the different tax authorities in the set 654 may be very large. In such use cases, tax jurisdictions such as a country, a state, a city, a municipality, etc., correspond to domains discussed herein.
[0160] For a specific determination of a tax obligation, the computer system 642 may receive one or more datasets. A sample received dataset 608 is shown just below line 602. The dataset 608 has values that can also be called dataset values, and be otherwise examples of what was described for the dataset values of the dataset 110 of FIG. 1. In this example, the computer system 632 transmits a request 624 that includes a payload 606, and the dataset 608 is received by the computer system 642 parsing the received payload 606. In this example, the single payload 606 encodes the entire dataset 608, but that is not required, as mentioned above. The dataset 608 may include transaction data for one or more transactions. For example, the dataset 608 may include one or more invoices.
[0161] In this example, the dataset 608 has been received because it is desired to determine any tax obligations arising from the buy-sell transaction 646. As such, the sample received dataset 608 has values that characterize attributes of the buy-sell transaction 646, as indicated by a correspondence arrow 650. Accordingly, in this example, the sample received dataset 608 has a value ID for an identity of the dataset 608 and / or the transaction 646. The dataset 608 also has a value PE for the name of the primary entity 638 or the user 636, which can be the seller making sales transactions, some perhaps online. The dataset 608 further has an optional value PD for relevant data of the primary entity 638 or the user 636, such as an address, place(s) of business, prior nexus determinations with various tax jurisdictions, and so on. The value PD is optional because it may be possible to look it up from the value PE. The dataset 608 also has a value SE for the name of the secondary entity 644, which can be the buyer. The dataset 608 further has a value SD for relevant data of the secondary entity 644, entity -driven exemption status, and so on. In some instances, the value SD can be optional, similarly with the value PD. The dataset 608 has a numerical value B2 for the sale price of the item sold. The dataset 608 may further have additional dataset values, as indicated0077888-00200 (AVAPAT_199) by the dot-dot-dot to the right side of the dataset 608. These values 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 646, a date and possibly also a time of the transaction 646, and so on.
[0162] The digital tax rules 614 are digital in that they are implemented for use by software, similarly with the rules 118 of FIG. 1. The digital tax rules 614 can be created so as to accommodate legal tax rules that the set 654 of different tax authorities 656, 658, etc., promulgate to apply within the boundaries of their tax jurisdictions. In the example of this diagram, only one sample digital tax rule is shown explicitly, namely rule T_RULE4 618. In this diagram, all other such rules are indicated by the vertical dot-dot-dots.
[0163] Then the computer system 642 may select a certain one of the digital tax rules 614. In this example, the rule T RULE4 618 is thus selected. In some examples, the tax rule(s) may be selected by first selecting a transaction scenario as described herein. The selection of this particular rule is indicated also by the fact that an arrow 620 begins from that rule. The arrow 620 is similar to the arrow 124.
[0164] The computer system 642 may thus select the certain rule T RULE4 618 responsive to one or more of the dataset values of the dataset 608. The impact of the dataset 608 in the selection is indicated by at least some of the arrows 616, similarly with the arrows 120. For example, it can be recognized that a condition of the digital tax rule T RULE4 618 is met by one or more of the values of the dataset 608. For instance, it can be further determined that, at the time of the sale, the buyer is located within the boundaries of a tax jurisdiction, that the seller has nexus with that tax jurisdiction, and that there is no tax holiday.
[0165] As such, the computer system 642 may produce the tax obligation 622, which is akin to producing the resource 126 of FIG. 1. The tax obligation 622 can be produced by the computer system 642 applying the certain digital tax rule T_RULE4 618, as indicated by the arrow 620. The impact of the dataset 608 in producing the tax obligation 622 is indicated by at least one of the arrows 616. In this example, the identified certain digital tax rule T_RULE4 618 may specify that a sales tax is due, the amount is to be determined by a multiplication of the sale price of the value 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.
[0166] As described herein, the computer system 642 may additionally or instead produce candidate data, such as additional transaction parameter 660. The additional transaction parameter 660 may be a parameter associated with the transaction that the computer system 642 may determine that, if present in the transaction data, would be likely to cause a different0077888-00200 (AVAPAT_199) and / or additional tax obligation to be calculated and / or a different resource scenario to be selected. The additional transaction parameter 660 may be, for example, an attribute of the product and / or service sold in the transaction. The additional transaction parameter 660 may be, for example, an attribute of the location of the buyer and / or seller.
[0167] The computer system 642 may then cause a notification 610 to be transmitted. In the example of FIG. 6, the notification 610 is caused to be transmitted by the computer system 642 as an answer to the received dataset 608. The notification 610 can be about an aspect of the tax obligation 622 and / or about an aspect of the additional transaction parameter 660, similarly with the notification 112 of FIG. 1. For instance, the notification 610 may inform that the tax obligation 622 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. The notification 610 may inform that the additional transaction parameter 660 has been identified, what it is, where it can be found, and / or request that data for the additional transaction parameter 660 be provided.
[0168] The notification 610 can be transmitted to one of an output device and another device that can be the remote device, from which the dataset 608 was received. The output device may be the screen of a local user or a remote user. The notification 610 may thus cause a desired image to appear on the screen, such as within a GUI and so on. The other device may be a remote device, as in this example. In particular, the computer system 642 causes the notification 610 to be communicated by being encoded as a pay load 612, which is carried by a response 626. The response 626 may be transmitted via the network 628 responsive to the received request 624. The response 626 may be transmitted to the computer system 632, or to the OPF 630, and so on. As such, the other device can be the computer system 632, or a device of the OPF 630, or the screen 634 of the user 636, and so on. In this example the single payload 612 encodes the entire notification 610, but that is not required, similarly with what is written above about encoding datasets in payloads. Of course, along with the aspect of the tax obligation 622, it is advantageous to embed in the payload 612 the ID value and / or one or more values of the dataset 608. This will help the recipient correlate the response 626 that they receive to their request 624, and therefore match the received aspect of the tax obligation 622 as the answer to the transmitted dataset 608.
[0169] The digital tax rules 614 can be implemented or organized in different ways. For example, these digital tax rules 614 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 622. These conditions may be expressed as logical conditions with ranges, dates, other data,0077888-00200 (AVAPAT_199) and so on. Values of the dataset 608 can be iteratively tested against these logical conditions according to arrows 616. 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.
[0170] As with the digital resource rules 118, the digital tax rules 614 may also be complex. While a certain one of them is eventually selected and applied to determine the tax obligation, more than one of them may be used for selecting that certain one. A transaction may utilize multiple rules to calculate multiple tax obligations.
[0171] FIG. 7 is a schematic illustration including example digital tax rules arranged in accordance with examples described herein. Referring now to FIG. 7, a dataset 702 can be as described for the dataset 608 of FIG. 6. In addition, a set 706 of digital tax rules is an example of the digital tax rules 614 of FIG. 6. A tax obligation 704 can be produced according to the arrow 750. The tax obligation 704 can be as described for the tax obligation 622. And it will be further recognized that FIG. 7 has many similarities with FIG. 2. This is intentional, so that portions of the explanations for FIG. 2 also apply to FIG. 7. The digital tax rules set 706 of FIG. 7 are example implementations of the digital resource rules 206 of FIG. 2, for example.
[0172] The set 706 of digital tax rules shows examples for digital tax rules, such as the digital tax rules 614 of FIG. 6. The set 706 of digital tax rules includes different subsets, into which the individual rules belong. In addition, there are hierarchical relationships among rules of different subsets, and / or of types. In this example, the set 706 includes a subset of tax authority selecting rules 736. The set 706 also includes subsets 744, 710, 708. etc., each for digital tax rules for tax authorities A, B, C, etc., respectively. A tax authority for which a subset of tax rules is thus provided could be associated with the primary entity 638, another tax authority could be associated with the secondary entity 644, and so on. In cases where digital tax rules are provided only for the tax authority A. the tax obligation 704 may be determined by starting from a 752c.
[0173] The subset 736 includes rules 738, 740, 742, etc. The subset 736 may be invoked, e.g., per arrow 752c, when multiple jurisdictions are candidates. These rules may select which tax jurisdiction’s rules will be applied, e.g., per arrow 752c. For instance, the rules of the subset 736 may be used to resolve whether a sales tax determination will be origin-based or destination-based. This may depend on appropriate rules of the tax jurisdictions themselves. Then the rules of the subset 736 may point to the digital tax rules of one or more0077888-00200 (AVAPAT_199) tax authorities whose legal tax rules will 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 744 and 710.
[0174] 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 744 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 710, 708, etc.
[0175] The subset 744 includes different ty pes of rules. In this example, the subset 744 includes tax precedence rules 712, tax computation rules 720, and tax override rules 728. In this example, the tax precedence rules 712 include rules 714, 716, 718, etc. The tax computation rules 720 include rules 722, 724, 726, etc. The tax override rules 728 include rules 730, 732, 734, etc.
[0176] In embodiments, one of the tax computation rules 720 may ordinarily be selected as the certain digital tax rule, which in FIG. 6 is shown as rule T RULE4 618. For instance, it may specify a percentage tax rate for the sales tax. The tax obligation 704 may be the percentage rate. Or the purchase price (base value B2) may be further learned from the dataset 702, e.g., per arrow 752c. and the tax obligation 704 may be the sales tax amount, produced by multiplying the percentage rate by the purchase price.
[0177] In addition, although not always required, the different types of rules within the subset 744 further have different hierarchies among them.
[0178] For a first instance, one of the tax precedence rules 712 may indicate which one of the tax computation rules 720 is to be selected, as generally indicated by an arrow 748. As an example, one of the tax precedence rules 712 may decide the taxability of a specific item indicated in the dataset 702. 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 w ith utensils, based on 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 720 is the appropriate one to use for the computation of the sales tax. As another example, one of the tax precedence rules 712 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 transaction 646 of FIG. 6 will be zero, and the tax obligation will be computed accordingly. As one more example, one of the tax precedence rules 712 may indicate that there is no economic nexus0077888-00200 (AVAPAT_199) for this transaction which, alone or in combination with other nexus determinations, may determine that no sales tax will be imposed.
[0179] For a second instance, even when one of the tax computation rules 720 is thus indicated, one of the tax override rules 728 may still override the indication, as generally indicated by an arrow 746. As an example, one of the tax override rules 728 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 728.
[0180] In this manner, systems described herein, such as the system of FIG. 6, may calculate a tax obligation 704. Further, as described herein, systems may additionally or instead provide one or more additional transaction parameters, such as additional transaction parameter 754 of FIG. 7.
[0181] FIG. 8 is a schematic illustration of tax calculations and scenarios arranged in accordance with examples described herein. FIG. 8 includes transaction parameter A 802, transaction parameter B 804, and transaction parameter C 806. FIG. 8 further depicts resource scenario A 810 and resource scenario B 818. FIG. 8 further depicts tax type A 812 and tax type B 822. The tax type A 812 may have sub-types including tax sub-type A 814, tax subtype B 816, and tax sub-type C 820.
[0182] The transaction parameters shown in FIG. 8 may be parameters included in transaction data provided by systems described herein, such as computer system 138 or computer 308 and / or ERP system 358 of FIG. 3. The transaction parameters shown in FIG. 8 may be parameters suggested by systems described herein, such as candidate data 158 of FIG. 1. candidate data 344 of FIG. 3, and / or additional transaction parameter 660 of FIG. 6 and / or additional transaction parameter 754 of FIG. 7.
[0183] The resource scenarios shown in FIG. 8 may be used to implement and / or be stored in resource scenario storage described herein, for example resource scenarios 332 of FIG. 3. The tax types and tax sub-types shown in FIG. 8 may be or may be implemented using digital rules described herein, such as those stored in digital rules 326 of FIG. 3 and / or digital tax rules 614 of FIG. 6 and / or digital resource rules 118 of FIG. 1.
[0184] The parameters, scenarios, types, and sub-types shown in FIG. 8 are exemplary. Additional, fewer, and / or different parameters, scenarios, types, and / or sub-types may be0077888-00200 (AVAPAT_199) present in other examples. In practice, systems described herein may manage a large number of parameters, scenarios, types, and sub-types.
[0185] In the example of FIG. 8, consider an example where transaction data is provided to a system described herein including transaction parameter A 802 and transaction parameter B 804. Utilizing those parameters, systems described herein (e.g., those described and depicted with reference to FIG. 1, FIG. 3, and / or FIG. 6) may select resource scenario A 810. Resource scenario A 810 may specify the calculation of tax type A 812, including tax subtype A 814 and tax sub-type B 816. In this manner, for transaction data including transaction parameter A 802 and transaction parameter B 804, systems described herein may be expected to return resource calculations that include tax type A 812, tax sub-type A 814, and tax subtype B 816.
[0186] However, consider an example where the transaction data includes transaction parameter A 802, transaction parameter B 804, and transaction parameter C 806. In this example, for the same transaction, the additional parameters result in a selection of both resource scenario A 810 and resource scenario B 818. The selection of both resource scenario A 810 and resource scenario B 818 results in the calculation of tax type A 812 and tax type B 822, including tax sub-type A 814, tax sub-type B 81 , and tax sub-type C 820.
[0187] Accordingly, examples of systems described herein may advantageously be utilized to compare transaction data received to historical transaction data, including historical transaction data from other entities. The comparison may include a calculation of a degree of coherence. The comparison may allow systems described herein to identify one or more additional candidate data (e.g., transaction parameters) which, if present, may result in additional and / or different resource calculations. Accordingly, in the example of FIG. 8, a system receiving transaction data including transaction parameter A 802 and transaction parameter B 804 may compare the transaction data with historical transaction data, and find similar transactions. However, the systems may recognize that other transactions including transaction parameter A 802 and transaction parameter B 804 include transaction parameter C 806. Further, the systems may recognize the inclusion of the additional transaction parameter, transaction parameter C 806, results in additional resource scenario selections and / or calculations - e.g., resource scenario B 818, including tax type B 822 and tax sub-fype C 820 in the example of FIG. 8. Accordingly, the systems described herein may request transaction parameter C 806 from entities providing transaction data including only transaction parameter A 802 and transaction parameter B 804.0077888-00200 (AVAPAT_199)
[0188] Examples of systems described herein accordingly may find use in the calculation and reporting of beverage and alcohol taxes, insurance taxes, excise taxes, lodging taxes, and / or cross-border VAT amounts. These are all examples of resource calculations and / or tax obligations described herein.
[0189] An example of a use case involving beverage and alcohol taxes is now considered. For example, the enterprise 302 may be a seller of beverages, including alcoholic beverages. The ERP system 358 may be used to provide transaction data regarding alcoholic beverage sales to the server computer 322. which may perform various tax calculations.
[0190] For example, the online software platform 320 including server computer 322 may calculate several different taxes on alcoholic beverage transactions when applicable, and in accordance with resource scenarios 332 and / or digital rules 326. For example, the computation engine 310 may calculate sales tax, mark up tax (e.g., specific taxes applying to alcohol transactions in particular states), pass-through excise tax (e.g., several states, including Kentucky, mandate excise taxes will be passed through to the end customer, however, this may not be the normal behavior for excise taxes, which are often mandated to not be passed through to the end customer and instead will be paid by the seller, such as the winery / brewery / distiller itself), and / or non-pass-through excise tax (e.g., taxes which the seller such as the winery / brewery / distiller should pay itself and should not pass through to the end customer).
[0191] Some of these excise taxes are based on additional information of a sale such as net volume of product sold and / or percentage of alcohol content. The POS systems used by enterprise 302 to sell product to customer 306 and / or invoicing and / or billing systems included in ERP system 358 may not be configured to gather all of this information at invoice level. In this case, when enterprise 302 passes transaction data without this information to the online software platform 320 using server computer 322, the online software platform 320 will not be able to calculate the excise taxes appropriately. However, the online software platform 320 including server computer 322 would still be able to calculate sales tax and markup tax.
[0192] However, when the server computer 322 receives transaction data from ERP system 358 including a product identification of an alcoholic beverage and a jurisdiction indication of a state or other jurisdiction imposing excise taxes, the computation engine 310 and / or recommendation system 338 may evaluate coherence of the transaction data against historical transaction data 334 and recommend net volume and / or percentage alcohol content as candidate data 344. The server computer 322 may look for authorization to obtain this0077888-00200 (AVAPAT_199) information and request the candidate data from ERP system 358. such as from an inventory or other system used to maintain data regarding attributes of the products sold. The computation engine 310 may request the candidate data 344 for transactions received from the invoicing system - e.g., using product identification from the invoicing system of ERP system 358.
[0193] This feature may allow example online software platforms described herein, including online software platform 320, to infer what other types of taxes are generally calculated on such a transaction based on the OSPs coding and grouping of tax types into scenarios as well as continuous learning of the association of taxes to be calculated together. The OSP will also look at the likelihood of passing extra information on such transactions. Correlating both of these facts in some examples may allow the OSP to recommend missing information and then allow the user to choose behavior for this information - either default it from a set of values which are either provided by the user in configuration or defaulted by the OSP as it continuously learns the user’s transactions or prompts user for extra information.
[0194] Another example use case for systems described herein includes insurance premium taxes. For calculating taxes on insurance premiums, the information used varies from jurisdiction to jurisdiction. Enterprise systems, such as the computer 308 and / or ERP system 358 of FIG. 3 and / or computer systems of insurance providers generally do not provide this guidance while writing insurance premiums. Accordingly, the ERP system 358 may not be able to adequately communicate the information to the online software platform 320 and / or server computer 322 for use in calculating taxes on insurance premiums. Providing limited information about insurance premium writing may result in taxes that are applicable on such insurance categories. The tax calculations may not be wrong, however, they may not accurately cover the rates and range of taxes that have applicability. For a global solution, it could be overwhelming for a particular insured and / or insurance provider to provide information at that level.
[0195] For example, in Austria for motor vehicle insurance, the tax rate may be determined using the engine size of the motor vehicle in kW. However, other countries may not utilize this information. In the United Kingdom or another country that does not utilize motor size, obtaining the motor size and reporting the motor size may be a waste of time and make the system cumbersome and / or prevents adoption or use. Nonetheless, without providing the engine size, the tax cannot be calculated properly for Austria. Examples of systems described herein accordingly advantageously allow for collection of additional transaction data in limited circumstances when such data would result, or would be likely to result, in the calculation of an additional or revised tax calculation.0077888-00200 (AVAPAT_199)
[0196] For example, the ERP system 358 of FIG. 3 may provide transaction data to the server computer 322 regarding a motor vehicle insurance premium. The transaction data may include an identification of the vehicle and the jurisdiction for the premium. The server computer 322, such as the computation engine 310 and / or the recommendation system 338 may compare the transaction data to the historical transaction data 334. In the case of the United Kingdom or a country that does not utilize engine size in a tax calculation, in some examples the computation engine 310 and / or the recommendation system 338 may not identify additional data in similar transactions stored in historical transaction data 334 - e.g., motor vehicle insurance transactions in the United Kingdom. In some examples, the computation engine 310 and / or the recommendation system 338 may identify similar transactions as motor vehicle transactions in Austria and may consider engine size as candidate data 344. However, the computation engine 310 and / or recommendation system 338 may identify that the additional engine size data would not result in additional or changed tax liability for the transaction data pertinent to the United Kingdom. For example, the computation engine 310 and / or the recommendation system 338 may access the digital rules 326 to determine, for the present transaction, no rule would apply using the candidate data and the present jurisdiction (e.g., the United Kingdom). Accordingly engine size is not used as candidate data 344 and not requested from the ERP system 358. In the case of the receipt of transaction data received pertaining to motor vehicle insurance premiums in Austria, the computation engine 310 and / or the recommendation system 338 may identify similar transactions in the historical transaction data 334, which include motor vehicle insurance premiums in Austria. The computation engine 310 and / or recommendation system 338 may determine that engine size was used to calculate a tax liability in those transactions, and accordingly, engine size may be identified as candidate data 344. In such an example, the server computer 322 may query the ERP system 358 for engine size information based on the motor vehicle identified in the received transaction data.
[0197] Accordingly, OSPs described herein may evaluate data with respect to similar jurisdictions and / or items to predict what liabilities should arise and / or improve the transaction scenario. A machine learning model may be trained based on weighted parameters to identify missing information in a transaction. The machine learning model may be refined through feedback, such as by users confirming whether the inferred data in fact existed and was not provided and / or whether the addition of the data caused another tax liability to be calculated.
[0198] FIG. 9 is a schematic illustration of a UI arranged in accordance with examples described herein. FIG. 9 depicts user interface (UI) 904 on screen 902. The screen 902 may0077888-00200 (AVAPAT_199) be used to implement and / or may be implemented by the screen 140 of FIG. 1 in some examples, and / or the computer 308 of FIG. 3. The UI 904 may be an interface to online software platforms described herein, such as online software platform (OSP) 154 of FIG. 1 and / or online software platform 320 of FIG. 3.
[0199] The UI 904 depicted in FIG. 9 is exemplary. Different displayed text and / or interactive elements may be used in other examples.
[0200] In the example of FIG. 9, the screen 902 may display options for a user (e.g., an admin of an enterprise and / or ERP system described herein) to authorize an online software platform on how to proceed when candidate data and / or additional transaction parameters are identified as described herein.
[0201] The screen 902 of FIG. 9 displays a question “What to do when we sense missing information on your transaction which if provided would calculate more taxes?” In this manner, online software platforms described herein may seek authorization from enterprises (e.g.. client systems) regarding how to proceed when candidate data and / or additional transaction parameters are identified.
[0202] The UI 904 provides radio buttons for a user to select a preferred action responsive to the identification of candidate data. While radio buttons are shown in FIG. 9. other interactive elements may be used in other examples, such as one or more buttons, touch regions, spoken words, or other input may be used to make a selection.
[0203] In the example of FIG. 9, a user may request that the online software platform “throw an error and do not proceed with tax calculation.” If this selection is made, e g., by enterprise 302 of FIG. 3, an indication of the selection may be stored in storage accessible to the online software platform, e.g., in enterprise config 336 of FIG. 3. When candidate data and / or additional transaction parameters are identified by the online software platform, the platform may search for authorization (e.g., in block 508 of FIG. 5), such as by accessing enterprise config 336, and may determine that the enterprise had requested instead that the platform return an error. Accordingly, the online software platform 320 of FIG. 3 may not calculate resource obligations on a transaction where candidate data and / or additional transaction parameters were identified as described herein. Instead, the online software platform 320 may report an error to the computer 308.
[0204] Alternatively, in the example of FIG. 9, a user may request that the online software platform “calculate the taxes you can with the information provided.” If this selection is made, e.g., by enterprise 302 of FIG. 3, an indication of the selection may be stored in storage accessible to the online software platform, e.g., in enterprise config 336 of FIG. 3. When0077888-00200 (AVAPAT_199) candidate data and / or additional transaction parameters are identified by the online software platform, the platform may search for authorization (e.g., in block 508 of FIG. 5), such as by accessing enterprise config 336, and may determine that the enterprise had requested that the platform simply calculate the resources on the basis of the received data. Accordingly, the online software platform 320 of FIG. 3 may calculate resource obligations on a transaction without using candidate data and / or additional transaction parameters identified as described herein. Instead, the online software platform 320 may calculate the resource (e.g., tax obligations) without use of the candidate data and / or the additional transaction parameters, and report the resource to the computer 308.
[0205] If users intend to authorize the online software platform to act on missing information (e.g., candidate data and / or additional transaction parameters), the user may select the radio button in FIG. 9 for ‘"Upon sensing the missing information" and make a selection for how the online software platform should act on the identification of missing information. One option that a user may select in FIG. 9 is “default the missing information to the values provided in configuration and calculate taxes.” If this selection is made, e.g., by enterprise 302 of FIG. 3, an indication of the selection may be stored in storage accessible to the online software platform, e.g., in enterprise config 336 of FIG. 3. When candidate data and / or additional transaction parameters are identified by the online software platform, the platform may search for authorization (e.g., in block 508 of FIG. 5), such as by accessing enterprise config 336, and may determine that the enterprise had requested that the platform utilize default values. Default values for certain candidate data and / or additional transaction parameters may be stored, for example, in enterprise config 336. In some examples, the default values may be provided by the enterprise, such as by enterprise 302 using ERP system 358. Accordingly, the online software platform 320 of FIG. 3 may calculate resource obligations on a transaction using default values for candidate data and / or additional transaction parameters identified as described herein. The resources (e.g., taxes) calculated using the default values may be reported to the enterprise, such as to computer 308.
[0206] Another option that a user may select in FIG. 9 is “alert and prompt user to provide missing information.” If this selection is made, e.g.. by enterprise 302 of FIG. 3. an indication of the selection may be stored in storage accessible to the online software platform, e.g., in enterprise config 336 of FIG. 3. When candidate data and / or additional transaction parameters are identified by the online software platform, the platform may search for authorization (e.g., in block 508 of FIG. 5), such as by accessing enterprise config 336, and may determine that the enterprise had requested that the platform prompt the user to provide the missing information. Accordingly, the online software platform 320 of FIG. 3 may prompt a client0077888-00200 (AVAPAT_199) system (e.g., computer 308 and / or ERP system 358) to provide the candidate data and / or additional transaction parameters. In some examples, the online software platform 320 may query the computer 308 and / or ERP system 358 for the candidate data and / or additional transaction parameters. On receipt of the candidate data and / or additional transaction parameters, the online software platform 320 may calculate resource obligations on a transaction using the initially-provided transaction data and the additional candidate data and / or additional transaction parameters. The resources (e.g., taxes) calculated using the default values may be reported to the enterprise, such as to the computer 308.
[0207] Another option that a user may select in FIG. 9 is “proceed with calculation and later notify user of missing information which could be passed to calculate additional taxes.” If this selection is made, e.g., by enterprise 302 of FIG. 3, an indication of the selection may be stored in storage accessible to the online software platform, e.g., in enterprise config 336 of FIG. 3. When candidate data and / or additional transaction parameters are identified by the online software platform, the platform may search for authorization (e.g., in block 508 of FIG. 5), such as by accessing enterprise config 336, and may determine that the enterprise had requested that the platform proceed with a calculation on the basis of the existing transaction data and later prompt the client system to provide additional information. Accordingly, the online software platform 320 of FIG. 3 may calculate resource obligations on a transaction without using candidate data and / or additional transaction parameters identified as described herein. Instead, the online software platform 320 may calculate the resource (e.g., tax obligations) without use of the candidate data and / or the additional transaction parameters, and report the resource to the computer 308. The resources (e.g., taxes) calculated using the default values may be reported to the enterprise, such as to the computer 308, together with information regarding the candidate data and / or additional transaction parameters and a request to provide the candidate data and / or additional transaction parameters for the calculation of additional or updated resource amounts.
[0208] In an example aspect, a method includes receiving, at an online software platform, transaction data for an entity, calculating, by the online software platform, resource obligations associated with the transaction data, comparing the transaction data with historical transaction data associated with additional entities, the historical transaction data stored in storage accessible to the online software platform, identifying, based on said comparing, candidate data associated with the transaction data, where the candidate data causes at least one additional resource obligation, searching for authorization to obtain the candidate data based on the identifying, and responsive to accessing the authorization, querying a client system for the candidate data.0077888-00200 (AVAPAT_199)
[0209] The method may also include where said identifying includes inferring, using a machine learning model, the candidate data. The method may also include where said comparing includes evaluating data coherence. The method may also include where the transaction data includes data for calculation of sales tax and the candidate data includes data for calculation of excise tax. The method may also include where the transaction data includes data for calculation of sales tax and the candidate data includes data for calculating a tax based on an insurance premium. The method may also include where the authorization is received through a user interface requesting authorization to prompt a user responsive to a determination of candidate data. The method may also include where said querying the client system for the candidate data includes configuring a connector portion of a computing system to transmit the candidate data to the online software platform.
[0210] Example methods may further include receiving feedback on the candidate data. Example methods may also include updating the machine learning model based on the feedback. Example methods may also include where said data coherence includes a likelihood of the candidate data being present in the historical transaction data together with other of the transaction data. Example methods may also include where the transaction data includes price and where the candidate data includes percentage of alcohol content.
[0211] In another example aspect, at least one non-transitory computer-readable storage medium is provided, the computer-readable storage medium including instructions that when executed by a computer, cause the computer to perform operations includes receive, at an online software platform, transaction data for an entity, calculate, by the online software platform, resource obligations associated with the transaction data, compare the transaction data with historical transaction data associated with additional entities, the historical transaction data stored in storage accessible to the online software platform, identify, based on said comparing, candidate data associated with the transaction data, where the candidate data causes at least one additional resource obligation, search for authorization to obtain the candidate data based on the identifying, and responsive to accessing the authorization, query' a client system for the candidate data.
[0212] The computer-readable storage medium may also include instructions where said identifying includes inferring, using a machine learning model, the candidate data. The computer-readable storage medium may also include instructions where said comparing includes evaluate data coherence. The computer-readable storage medium may also include instructions where the transaction data includes data for calculation of sales tax and the candidate data includes data for calculation of excise tax. The computer-readable storage medium may also include instructions where the transaction data includes data for calculation0077888-00200 (AVAPAT_199) of sales tax and the candidate data includes data for calculating a tax based on an insurance premium. The computer-readable storage medium may also include instructions where the authorization is received through a user interface request authorization to prompt a user responsive to a determination of candidate data. The computer-readable storage medium may also include instructions where said querying the client system for the candidate data includes configure a connector portion of a computing system to transmit the candidate data to the online software platform,
[0213] In another example aspect, a system includes a first computer system configured to generate transaction data. The system also includes a second computer system configured to extract the transaction data from the first computer system in accordance with a particular configuration, the second computer system including a processor. The system also includes a second computer system configured to extract the transaction data from the first computer system in accordance with a particular configuration, the second computer system including a memory storing instructions that, when executed by the processor, cause the second computer system to perform operations including receive the transaction data, compare the transaction data with historical transaction data associated with additional entities, the historical transaction data stored in storage accessible to the second computer system, identify, based on said compare, candidate data associated with the transaction data, where the candidate data contributes to at least one additional resource obligation, and responsive to authorization, update the particular configuration to further extract the candidate data.
[0214] The system may also include where said identifying includes inferring, using a machine learning model, the candidate data. The system may also include where said comparing includes evaluate data coherence. The system may also include where the transaction data includes data for calculation of sales tax and the candidate data includes data for calculation of excise tax. The system may also include where the transaction data includes data for calculation of sales tax and the candidate data includes data for calculating a tax based on an insurance premium. The system may also include where the second computer system further provides a user interface request authorization to prompt a user responsive to a determination of candidate data.
[0215] In the methods described herein, each operation can be performed as an affirmative act or operation 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. It will be recognized that the methods and the operations may be implemented in a number of ways, including using systems, devices, and implementations described above. In addition, the order of operations is not constrained to what is shown, and different orders may0077888-00200 (AVAPAT_199) be possible according to different embodiments. Examples of such alternate orderings may include overlapping, interleaved, interrupted, reordered, incremental, preparatory, supplemental, simultaneous, reverse, or other variant orderings, unless context dictates otherwise. Moreover, in certain 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.
[0216] Details have been included herein to provide a thorough understanding. In some instances, well-known aspects have not been described, in order to not obscure unnecessarily this description.
[0217] Some technologies or techniques described in this document may be known. Even then, however, it does not necessarily follow that it is known to apply such technologies or techniques as described in this document, or for the purposes described in this document.
[0218] This description includes one or more examples, but this fact does not limit how the technology may be practiced. Indeed, examples, instances, versions, or embodiments of the technology may be practiced according to what is described, or yet differently, and also in conjunction with other present or future technologies. Other such embodiments include combinations and sub-combinations of features described herein, including for example, embodiments that are equivalent to the following: 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 a feature from an embodiment and adding a feature extracted from another embodiment, while providing the features incorporated in such combinations and sub-combinations.
[0219] A number of embodiments are possible, each including various combinations of elements. When one or more of the appended drawings - which are part of this specification - are taken together, they may present some embodiments with their elements in a manner so compact that these embodiments can be surveyed quickly. This is true even if these elements are described individually extensively in this text, and these elements are only optional in other embodiments.
Claims
0077888-00200 (AVAPAT_199)CLAIMSWhat is claimed is:
1. A method comprising: receiving, at an online software platform, transaction data for an entity; calculating, by the online software platform, resource obligations associated with the transaction data; comparing the transaction data with historical transaction data associated with additional entities, the historical transaction data stored in storage accessible to the online software platform; identifying, based on said comparing, candidate data associated with the transaction data, wherein the candidate data causes at least one additional resource obligation; searching for authorization to obtain the candidate data based on the identifying; and responsive to accessing the authorization, querying a client system for the candidate data.
2. The method of claim 1, wherein said identifying comprises inferring, using a machine learning model, the candidate data.
3. The method of claim 2, further comprising receiving feedback on the candidate data.
4. The method of claim 3, further comprising updating the machine learning model based on the feedback.
5. The method of claim 1, wherein said comparing comprises evaluating data coherence.
6. The method of claim 5, wherein said data coherence comprises a likelihood of the candidate data being present in the historical transaction data together with other of the transaction data.
7. The method of claim 1, wherein the transaction data includes data for calculation of sales tax and the candidate data includes data for calculation of excise tax.
8. The method of claim 7, wherein the transaction data comprises price and wherein the candidate data comprises percentage of alcohol content.0077888-00200 (AVAPAT_199)9. The method of claim 1, wherein the transaction data includes data for calculation of sales tax and the candidate data includes data for calculating a tax based on an insurance premium.
10. The method of claim 1. wherein the authorization is received through a user interface requesting authorization to prompt a user responsive to a determination of candidate data.
11. The method of claim 1, wherein said query ing the client system for the candidate data comprises configuring a connector portion of a computing system to transmit the candidate data to the online software platform.
12. At least one non- transitory computer-readable storage medium, the computer- readable storage medium including instructions that when executed by a computer, cause the computer to perform operations comprising: receive, at an online software platform, transaction data for an entity; calculate, by the online software platform, resource obligations associated with the transaction data; compare the transaction data with historical transaction data associated with additional entities, the historical transaction data stored in storage accessible to the online software platform; identify, based on said comparing, candidate data associated with the transaction data, wherein the candidate data causes at least one additional resource obligation; search for authorization to obtain the candidate data based on the identifying; and responsive to accessing the authorization, query7a client system for the candidate data.
13. The computer-readable storage medium of claim 12, wherein said identifying comprises inferring, using a machine learning model, the candidate data.
14. The computer-readable storage medium of claim 13, wherein the instructions further configure the computer to receive feedback on the candidate data.
15. The computer-readable storage medium of claim 14, wherein the instructions further configure the computer to update the machine learning model based on the feedback.
16. The computer-readable storage medium of claim 12, wherein said comparing comprises evaluate data coherence.0077888-00200 (AVAPAT_199)17. The computer-readable storage medium of claim 16, wherein said data coherence comprises a likelihood of the candidate data being present in the historical transaction data together with other of the transaction data.
18. The computer-readable storage medium of claim 12, wherein the transaction data includes data for calculation of sales tax and the candidate data includes data for calculation of excise tax.
19. The computer-readable storage medium of claim 18, wherein the transaction data comprises price and wherein the candidate data comprises percentage of alcohol content.
20. The computer-readable storage medium of claim 12, wherein the transaction data includes data for calculation of sales tax and the candidate data includes data for calculating a tax based on an insurance premium.
21. The computer-readable storage medium of claim 12, wherein the authorization is received through a user interface request authorization to prompt a user responsive to a determination of candidate data.
22. The computer-readable storage medium of claim 12, wherein said query ing the client system for the candidate data comprises configure a connector portion of a computing system to transmit the candidate data to the online software platform.
23. A system comprising: a first computer system configured to generate transaction data; and a second computer system configured to extract the transaction data from the first computer system in accordance with a particular configuration, the second computer system including: a processor; and a memory’ storing instructions that, when executed by the processor, cause the second computer system to perform operations comprising: receive the transaction data; compare the transaction data with historical transaction data associated with additional entities, the historical transaction data stored in storage accessible to the second computer system; identify, based on said compare, candidate data associated with the transaction data, wherein the candidate data contributes to at least one additional resource obligation; and0077888-00200 (AVAPAT_199) responsive to authorization, update the particular configuration to further extract the candidate data.
24. The system of claim 23, wherein said identifying comprises inferring, using a machine learning model, the candidate data.
25. The system of claim 24, wherein the operations further comprise receive feedback on the candidate data.
26. The system of claim 25, wherein the operations further comprise update the machine learning model based on the feedback.
27. The system of claim 23, wherein said comparing comprises evaluate data coherence.
28. The system of claim 27, wherein said data coherence comprises a likelihood of the candidate data being present in the historical transaction data together with other of the transaction data.
29. The system of claim 23, wherein the transaction data includes data for calculation of sales tax and the candidate data includes data for calculation of excise tax.
30. The system of claim 29, wherein the transaction data comprises price and wherein the candidate data comprises percentage of alcohol content.
31. The system of claim 23, wherein the transaction data includes data for calculation of sales tax and the candidate data includes data for calculating a tax based on an insurance premium.
32. The system of claim 23, wherein the second computer system further provides a user interface request authorization to prompt a user responsive to a determination of candidate data.
Citation Information
Patent Citations
Online software platform (OSP) accessing digital rules updated based on client inputs
US11722433B1
Accurate tax calculation
US20070136158A1
Online interactive notification platform for exploring possible tax nexus and implications
US20220067842A1