AUTOMATED PREPARATION AND TRANSMISSION OF ELECTRONIC REGISTRATIONS, DATA SHEETS AND RESOURCES
Systems and methods are disclosed for automated preparation and transmission of electronic registrations, data sheets and resources. This may include electronically initiating a process to collect data via a graphical user interface (GUI) to facilitate automated preparation of an electronic registration, including electronically obtaining a pre-existing entity identifier. The system may use the entity identifier to perform automated actions to electronically collect one or more support content. The system may generate the electronic registration based on the one or more support content and also receives interchange data. The system then automatically generates an electronic data sheet based on the registration and interchange data. The system may then electronically file the generated electronic data sheet, electronically issuing an alert to electronically request additional resources and automatically transmitting the finalized amount of resources to the domain.
The technical field relates to computer networks and automated preparation and transmission of electronic registrations, data sheets and resources in computer network technology, as discussed in more detail below.
BRIEF SUMMARYIndividuals and organizations generally participate in interchanges with other entities. Such interchanges might number in the thousands, millions, or billions, for example. These interchanges might further trigger additional action steps that the individuals and organizations become effectively obligated to perform in response to these interchanges. Generally speaking, these next action steps may include, among other things, generating and appropriately filing electronic data sheets. These further action steps may be required by a domain at which one or more parties to each interchange is associated. Accordingly, such large numbers of interchanges may also be associated with large numbers of domains, and each of the domains might establish significantly different action steps to be performed in response to the interchanges. For example, each respective domain might establish significantly different rules, or other logic, for appropriately cataloguing, tracking, and/or recording corresponding interchanges, as well as different rules for performing next action steps in response to these interchanges, such as by preparing and appropriately filing corresponding electronic data sheets.
The massive number of individuals, organizations, interchanges, and/or associated domains, and the complications resulting from different domains having significantly different rules, thereby creates a challenge in terms of properly tracking and recording the interchanges, appropriately calculating or determining the next action steps, and/or appropriately preparing and filing the corresponding electronic data sheets with each respective domain in accordance with each respective domain's potentially unique or different set of rules.
Additionally or alternatively, one particular challenge arising from the massive number of individuals, organizations, interchanges, and/or associated domains is from the potential desire of individuals or organizations to appropriately prepare and file the electronic data sheets with reduced, minimal, or even zero further intervention or disturbance. In other words, these individuals and organizations may appropriately desire for the electronic data sheets to be automatically generated and filed, on behalf of the individuals or organizations, in a manner that minimizes the disturbance to these individuals or organizations. More specifically, these individuals or organizations may appropriately desire for one or more entities, and/or corresponding network computing systems, to provide or submit resources to respective domains, in accordance with the electronic data sheets and in accordance with the potentially unique rules of each domain, without the individuals or organizations being further contacted or disturbed. Nevertheless, when providing or submitting resources on behalf of an individual or organization, there can arise a risk of the resources being provided without the individual or organization thereafter compensating for this provisioning of resources within an appropriate amount of time. Accordingly, the present disclosure discloses risk-reduction technologies that may address and remediate this additional challenge.
Such risk-reduction technologies may include electronically determining an estimated amount of resources to be transmitted based on an analysis of the interchange data associated with interchanges executed by users for hundreds or thousands of remote entity systems over the network simultaneously or concurrently (which is impossible to do in the human mind) to provide more accurate and efficient computer network operations for electronic data sheet filing and transmission of resources for various systems on the network, including for the entity systems and devices of systems on which the electronic data sheets are electronically filed, thus improving the technology of computer networks and the technology of electronic datasheet filing and electronic transmission of resources.
In particular, such simultaneous and/or concurrent electronic determining of estimated amounts of resources to be transmitted based on an analysis of the interchange data associated with interchanges executed by users for hundreds or thousands of remote entity systems over the network increases the speed at which the electronic services are provided (as opposed to the systems waiting for them to be performed serially). This also reduces data flow over the computer network by avoiding the entity systems having to resend requests over the network to perform the electronic services to receive updated data regarding actual current amounts of resources available that would otherwise be performed by the service engine to transmit the resources.
Furthermore, such electronic filing of the generated electronic data sheets with domains automatically such that further contacting the one or more users for electronically filing the generated electronic data sheets is avoided beyond the initial setup also reduces data flow over the computer network by avoiding the entity systems having to transmit requests and other data over the network to perform electronic intermediate and follow-up tasks and provide updated data after the initial setup that would otherwise be required to enable the generation and filing of the electronic data sheets.
Such electronically filing of the generated electronic data sheets with domains automatically such that further contacting the users for electronically filing the generated electronic data sheets is avoided beyond the initial setup may be performed by a filing engine for hundreds or thousands of entities via hundreds or thousands of remote entity systems over the network simultaneously or concurrently (which is impossible to do in the human mind) to provide more accurate and efficient computer network operations for electronic data sheet filing for various systems on the network, including for the entity systems and devices of systems on which the electronic data sheets are electronically filed, thus improving the technology of computer networks and the technology of electronic datasheet filing.
In particular, such simultaneous and/or concurrent electronic generating and filing of the electronic data sheet being performed by the filing engine for hundreds or thousands of entities via hundreds or thousands of remote systems over the network increases the speed at which the electronic services are provided (as opposed to the systems waiting for them to be performed serially). This also reduces data flow over the computer network by avoiding the entity systems having to resend requests over the network to perform the electronic services and provide updated data due to lag times that would otherwise be experienced by the entity systems between when the original request was sent and when the electronic operations are able to be performed.
Thus, the systems and methods described herein for automated actions for electronically generating and filing of electronic data sheets, automated risk-reduction and electronic determining of estimated amounts of resources to be transmitted improves the functioning of computer or other hardware, such as by reducing the processing, storage, and/or data transmission resources needed to perform various tasks, including preparation and submission of electronic registration, thereby enabling the tasks to be performed by less capable, capacious, and/or expensive hardware devices, and/or be performed with less latency, and/or preserving more of the conserved resources for use in performing other tasks or additional instances of the same task.
In view of the above, the present disclosure provides technical improvements in computer networks and existing computerized systems to facilitate the generation and automatic filing of electronic data sheets.
Furthermore, an example embodiment includes an automated electronic registration preparation and submission system that electronically generates, via a registration engine, an electronic registration based on extracted data. The system may electronically initiate a process to collect data via a graphical user interface (GUI) to facilitate automated preparation of an electronic registration before initiating a process to remit resources from a first entity (e.g., primary entity) to one or more recipient entities based on relationship instances between the primary entity and a plurality of secondary entities.
The system may obtain a pre-existing entity identifier that had been previously used by an electronic system of at least one third party authority entity to identify a primary entity. The system may electronically associate the pre-existing entity identifier with the primary entity and use it to perform automated actions to electronically collect support content from the Internet or other sources regarding the primary entity to facilitate automated preparation of the electronic registration document. The system may then electronically identify data from the support content relevant to the electronic registration and electronically extract the identified data from the support content in response to electronically identifying the data. The system may also electronically verify the extracted data before electronically generating and submitting the electronic registration based on the extracted data.
Such processing and generating the registration may be performed by the registration engine for hundreds or thousands of clients via hundreds or thousands of remote client devices over the network simultaneously or concurrently (which is impossible to do in the human mind) to provide more accurate and efficient computer network operations for electronic document generation for various systems on the network, including the client devices and devices of systems on which the electronic registrations are electronically submitted, thus improving the technology of computer networks and the technology of electronic document generation and registration.
In particular, such simultaneous and/or concurrent electronic generating and submitting of the registration being performed by the registration engine for hundreds or thousands of clients via hundreds or thousands of remote client devices over the network increases the speed at which the electronic services are provided (as opposed to the devices waiting for them to be performed serially). This reduces data flow over the computer network by avoiding the client devices having to resend requests over the network to perform the electronic services and provide updated data due to lag times that would otherwise be experienced by the client devices between when the original request was sent and the electronic operations are able to be performed. Thus, the systems and methods described herein for automated actions for automated preparation and submission of electronic registration improves the functioning of computer or other hardware, such as by reducing the processing, storage, and/or data transmission resources needed to perform various tasks, including preparation and submission of electronic registration, thereby enabling the tasks to be performed by less capable, capacious, and/or expensive hardware devices, and/or be performed with less latency, and/or preserving more of the conserved resources for use in performing other tasks or additional instances of the same task.
In some embodiments, user input may indicate where the client or associated entity is from or located. Based on this user input, the digital rules may be electronically consulted to automatically choose which web site or data source the system has to interact with to obtain certain information for the registration process. In various embodiments, the digital rules may be electronically consulted based upon modifiable workflow configurations.
An adaptive user interface (UI) to the system for processing registrations for registering with one or more remote systems may be presented on a client device. In an example embodiment, before electronically generating the registration based on the extracted data, the registration engine electronically determines, based on the extracted data, whether to electronically present a query via the adaptive UI for supplemental data regarding the entity associated with the client device to facilitate automated preparation of the electronic registration. The registration engine may automatically modify the adaptive UI in response to the determination whether to electronically present a query via the adaptive UI for the supplemental data. The registration engine may electronically present the query via the adaptive UI for the supplemental data. The registration engine may electronically receive the supplemental data over the network via the adaptive UI in response to electronically presenting the query via the adaptive UI for the supplemental data and then electronically verify the supplemental data.
As shown above and in more detail throughout the present disclosure, the present disclosure provides technical improvements in computer networks and existing computerized systems to facilitate accuracy, efficiency and speed of computing resources to perform automated electronic registration preparation and submission and electronic document generation.
These and other features and advantages of the claimed invention will become more readily apparent in view of the embodiments described and illustrated in this specification, namely in this written specification and the associated drawings.
The components in the drawings are not necessarily drawn to scale relative to each other. Like reference numerals designate corresponding parts throughout the several views.
The description that follows includes systems, methods, techniques, instruction sequences, and computing machine program products that embody illustrative embodiments of the disclosure. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, that embodiments of the inventive subject matter may be practiced without these specific details. In general, well-known structures and methods associated with underlying technology have not been shown or described in detail to avoid unnecessarily obscuring descriptions of the preferred embodiments.
A thick line 115 separates this diagram, although not completely or rigorously, into a top portion and a bottom portion. Above the line 115 the emphasis is mostly on entities, components, their relationships, and their interactions, while below the emphasis is mostly processing of data that takes place often within one or more of the components above the line 115.
Above the line 115, a sample computer system 195 according to embodiments is shown. The computer system 195 has one or more processors 194 and a memory 130. The memory 130 stores programs 131 and data 138. The one or more processors 194 and the memory 130 of the computer system 195 can thereby implement a filing engine 183. Additional implementation details for the computer system 195 are given later in this document.
The computer system 195 can be located in “the cloud.” In fact, the computer system 195 may optionally be implemented as part of an OSP 198. The OSP 198 can be configured to perform one or more predefined services, for example, via operations of the filing engine 183. Such services can be searches, determinations, computations, verifications, notifications, the transmission of specialized information, including data that effectuates payments or remits resources, the generation and transmission of documents, the online accessing other systems to effect registrations, and so on, including what is described in this document. Such services can be provided as a Software as a Service (SaaS).
A user 192 may be standalone. The user 192 may use a computer system 190 that has a screen 191, on which User Interfaces (UIs) may be shown. Additional sample implementation details for the computer system 190 are given later in this document. In embodiments, the user 192 and the computer system 190 are considered part of primary entity 193, which can be referred to also merely as an entity. In such instances, the user 192 can be an agent of the entity 193, and even within a physical site of the entity 193, although that is not necessary. In embodiments, the computer system 190 or other device of the user 192 or the entity 193 are client devices for the computer system 195.
The computer system 190 may access the computer system 195 via a communication network 188, such as the internet. In particular, the entities and associated systems of
Downloading or uploading may be permitted from one of these two computer systems to the other, and so on. Such accessing can be performed, for instance, with manually uploading files, like spreadsheet files, etc. Such accessing can also be performed automatically as shown in the example of
In one such architecture, a device remote to the filing engine 183, such as computer system 190, may have a certain application (not shown) and a connector (not shown) that is a plugin that sits on top of that certain application. The connector may be able to fetch from the remote device the details required for the service desired from the OSP 198, form an object or payload 134, and then send or push a request 184 that carries the payload 134 to the filing engine 183 via a service call. The filing engine 183 may receive the request 184 with the payload 134. The filing engine 183 may then apply digital rules 170 to the payload 134 to determine a requested resource 179, form a payload 137 that is an aspect of the electronic data sheet 179, and then push, send, or otherwise cause to be transmitted a response 187 that carries the payload 137 to the connector. The connector reads the response 187, and forwards the payload 137 to the certain application.
In an alternative such architecture, a device remote to the filing engine 183, such as computer system 190, may have a particular application (not shown). In addition, the computer system 195 may implement a REST (Representational State Transfer) API (Application Programming Interface) (not shown). 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 HTTP (Hyper Text Transfer Protocol) when used for Web APIs. This alternative architecture enables the primary entity 193 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 required for the service desired from the OSP 198, and thus send or push the request 184 to the REST API. In turn, the REST API talks in background to the filing engine 183. Again, the filing engine 183 determines the requested resource 179, and sends an aspect of it back to the REST API. In turn, the REST API sends the response 187 that has the payload 137 to the particular application.
Moreover, in some embodiments, data from the computer system 190 and/or from the computer system 195 may be stored in an Online Processing Facility (OPF) 189 that can run software applications, perform operations, and so on. In such embodiments, requests and responses may be exchanged with the OPF 189, downloading or uploading may involve the OPF 189, and so on. In such embodiments, the computer system 190 and any devices of the OPF 189 can be considered to be remote devices, at least from the perspective of the computer system 195.
In embodiments, the computer system 195 receives one or more datasets. A sample received dataset 135 is shown below the line 115. The dataset 135 may be received by the computer system 195 in a number of ways. In some embodiments, one or more requests may be received by the computer system 195 via a network. In this example, a request 184 is received by the computer system 195 via the network 188. The request 184 has been transmitted by the remote computer system 190. The received one or more requests can carry payloads. In this example, the request 184 carries a payload 134. In such embodiments, the one or more payloads may be parsed by the computer system 195 to extract the dataset. In this example, the payload 134 can be parsed by the computer system 195 to extract the dataset 135. In this example the single payload 134 encodes the entire dataset 135, 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 188, some beyond the control of the user 192 or OSP 198, and some within such control.
The dataset 135 has values that can be numerical, alphanumeric, Boolean, and so on, as needed for what the values characterize. For example, an identity value ID may indicate an identity of the dataset 135, so as to differentiate it from other such datasets. At least one of the values of the dataset 135 may characterize an attribute of a certain one of the entities such as primary entity 193, and/or intermediary entities, as indicated by arrow 199. (It should be noted that the arrows 199 describe a correspondence, but not the journey of data in becoming the received dataset 135.) For instance, a value D1 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 B1 may be a numerical base value for an aspect of the dataset, and so on. The aspect of the dataset may be the aspect of the value that characterizes the attribute, an aspect of the reason that the dataset was created in the first place, an indication of whether an interchange with a secondary entity is via an intermediary entity, an indication of whether an electronic data sheet associated with the interchange is received via an intermediary entity, an indication of an identity or other characteristic of the intermediary entity, and so on. The dataset 135 may further have additional such values, as indicated by the horizontal dot-dot-dot to the right of the dataset 135. In some embodiments, each dataset, such as dataset 135 corresponds to one interchange. In some embodiments, the dataset 135 may correspond to a plurality of interchanges and include such respective values for each respective interchange of the plurality of interchange instances. In some embodiments, the dataset 135 has values that characterize attributes of each of the primary entity 193, a secondary entity, and also an intermediary entity, as discussed above, but that is not required. In some embodiments, the primary entity 193 may further include the intermediary entity or the secondary entity and communications described herein such as the request 184 and response 187 may be additionally or instead between the intermediary entity or secondary entity and the computer system 195.
In embodiments, stored digital rules 170 may be accessed by the computer system 195. These rules 170 are digital in that they are implemented for use by software. For example, these rules 170 may be implemented within programs 131 and data 138. The data portion of these rules 170 may alternately be implemented in memories in other places, which can be accessed via the network 188. These rules 170 may be accessed responsive to receiving a dataset, such as the dataset 135.
The digital rules 170 may include main rules, which can thus be accessed by the computer system 195. In this example, three sample digital main rules are shown explicitly, namely M_RULE5 175, M_RULE6 176, and M_RULE7 177. In this example, the digital rules 170 also include digital precedence rules P_RULE2 172 and P_RULE3 173, which can thus be further accessed by the computer system 195. The digital rules 170 may include additional rules and types of rules, as suggested by the vertical dot-dot-dots.
In embodiments, a certain one of the digital main rules may be identified from among the accessed stored rules by the computer system 195. In particular, values of the dataset 135 can be tested, according to arrows 171, against logical conditions of the digital main rules, as described later in this document. In this example, the certain main rule M_RULE6 176 is thus identified, which is indicated also by the beginning of an arrow 178 that is described in more detail later in this document. Identifying may be performed in a number of ways, and depending on how the digital main rules are implemented. An example is now described.
Referring now also to
In embodiments, therefore, identifying is performed by recognizing, by the computer system 195, that a certain condition of a certain one of the accessed digital main rules is met by one or more of the values of the dataset. An example of the operations of recognizing that a condition is met and thus identifying an applicable rule is shown by flowchart portion 200 of
From what was mentioned in connection with
A number of examples are possible for how to recognize that a certain condition of a certain digital rule is met by at least one of the values of the dataset. Depending on the type of data, different rules may be applied. 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 and may include political boundaries. For example, the region could be geographic, within the space of a city, a county, 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. In such embodiments, the certain condition could be met responsive to the characterized attribute of the dataset being in the space and within the boundary of the region instead of outside the boundary. For instance, the attribute could be a location of the entity, and the one or more values of the dataset 135 that characterize the location could be one or more numbers or an address, or longitude and latitude. The 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 by rendering the characterized attribute in units comparable to those of the boundary. For example, the characterized attribute could be an address that is rendered into longitude and latitude coordinates, and so on.
The above embodiments are only examples, and not limiting. For instance, the example of
For another instance, once it is determined that a consequent is to be applied, execution may even exit the flowchart portion 200. Or, as shown, it may be determined that more than one of the digital main rules is to be applied. In particular, operation 286 may give the answer YES such that consequent CT6 is to be applied, and operation 287 may also give the answer YES such that consequent CT7 is to be applied.
Where more than one of the digital main rules are found that could be applied, there are additional possibilities. For instance, the computer system 195 of
In the context of filing engine 183, another example is for how to recognize that a certain condition of a certain digital rule is met for the electronic data sheet is to be prepared, generated, and/or filed in association with one or more domains. If such a condition is met, the digital rules 170 may indicate to actually prepare, generate, and/or file the electronic data sheet in association with the corresponding domain.
In embodiments, an electronic data sheet may be produced for the dataset 135 by the computer system 195 applying the certain consequent of the certain digital main rule. The electronic data sheet can correspond to a computational result, a document, an item of value, a representation of an item of value, etc., made, created or prepared for the user 192, the primary entity 193, a secondary entity, an intermediary entity, etc., on the basis of the attribute. As such, in some embodiments, the electronic data sheet is produced by a determination and/or a computation. In the example of
The electronic data sheet 179 may be produced in a number of ways. For example, the certain consequent can be applied to one or more of the values of the dataset 135. For instance, one of the values of the dataset 135 can be a numerical base value, e.g. B1, that encodes an aspect of the dataset 135, as mentioned above. In such cases, applying the certain consequent may include performing a mathematical operation on the base value B1. For example, applying the certain consequent may include multiplying the base value B1 with a number indicated by the certain consequent. 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 rule, or be stored in a place indicated by the certain rule, and so on.
As mentioned above, in some embodiments two or more digital main rules may be applied. For instance, referring again to
In such embodiments, the electronic data sheet may be produced by the computer system applying the certain consequent and the additional consequent. For instance, where the base value B1 is used, applying the certain consequent may include multiplying the base value B1 with a first number indicated by the certain consequent, so as to compute a first product. In addition, applying the additional consequent may include multiplying the base value B1 with a second number indicated by the additional consequent, so as to compute a second product. And, the electronic data sheet may be produced by summing the first product and the second product.
In embodiments, a notification, such as notification 102, can be caused to be transmitted, e.g., via the network 188, by the computer system. A notification may be asynchronous, a flag, or an indication of information. For example, a notification may be an API call or part of one. In other embodiments, the notification may be a synchronous activity. The notification can include or can be about an aspect of the electronic data sheet 179. In the example of
The notification 102 can be transmitted to one of an output device and another device. The output device may be the screen of a local user or a remote user. The notification 102 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. In some embodiments, the notification 102 may not be displayed on the screen. The other device can be the remote device, from which the dataset 135 was received, as in the example of
In an example embodiment, there may be a plurality of interchanges between the primary entity 193 and one or more secondary entities. In some embodiments, such interchanges are between the primary entity 193 and one or more secondary entities via one or more intermediary entities. Each interchange may be associated with one or more respective domains of a plurality of domains. Also, each interchange may be associated with one or more respective intermediary entities, which handles or facilitates creation of the interchange. For example, an interchange may be performed by the primary entity 193 via a intermediary entity. In various embodiments, a domain may be a region defined by a boundary as discussed above or may be an entity representing or otherwise associated with the region. For example, the region could be geographic, within the space of a city, a county, a state, a country, a continent or the earth. A plurality of interchanges may result in a requirement that an electronic data sheet, such as an electronic reporting document associated with the primary entity 193, be prepared regarding an amount of resources due to one or more of the plurality of domains, that the document be sent to one or more of the plurality of domains and that resources possibly be remitted to one or more of the plurality of domains. A domain as used herein may refer to a geographic area or to one or more authorities (or computerized systems controlled by such authorities) that set or define rules or digital rules for such a geographic area or domain as described herein. The OSP 198 may perform or facilitate such electronic actions.
For example, in one embodiment, primary entity 193 may have an interchange with secondary entity and that particular interchange may be associated with one or more domains and with an electronic data sheet associated with the primary entity 193. The association of the interchange with the one or more domains may be based on a variety of characteristics including, but not limited to: a relationship of one or more of the primary entity and secondary entity with the particular domain; a location of one or more of the primary entity and secondary entity within or associated with the particular domain; a region or location associated with one or more of the primary entity and secondary entity being within or associated with the particular domain; a previous relationship of one or more of the primary entity and secondary entity with the particular domain; a location of items associated with one or more of the primary entity and secondary entity within the particular domain; a number of relationships of one or more of the primary entity and secondary entity with the particular domain; a transfer of items associated with one or more of the primary entity and secondary entity to or from an entity within or associated with the particular domain; a transfer of data associated with one or more of the primary entity and secondary entity to or from an entity within or associated the particular domain, etc. The existence or identification of the interchange and/or one or more characteristics of the interchange may be defined or represented by values of dataset 135.
In some embodiments, for each interchange of the plurality of interchanges, the OSP 198 electronically identifies a rate to calculate an amount of resources due to one or more respective domains. For example, the primary entity 193 may send request 184 to the computer system 195 of OSP 198 for services that facilitate remitting resources due to one or more respective domains. The request 184 may include the existence or identification of the interchange and/or one or more characteristics of the interchange as part of payload 134. The filing engine 183 may then apply digital rules 170 to the interchange and/or one or more characteristics of the interchange to identify or otherwise determine the rate to calculate an amount of resources due to one or more respective domains associated with the interchange.
For example, digital precedence rule P_RULE2 172 may decide that rule M_RULE5 175 is to be applied when a particular condition is met. Digital precedence rule P_RULE2 172 may include a condition that indicates if a particular interchange is associated with a particular domain, then rule M_RULE5 175 is to be applied. The filing engine 183 may determine that the condition is met due to one or more values of dataset 135 indicating the particular interchange and that the particular interchange is associated with the particular domain. Thus, as a consequent of precedence rule P_RULE2 172, the filing engine 183 applies rule M_RULE5 175. Rule M_RULE5 175 may include a condition CN5 that indicates if a particular party to an interchange originates from a particular source or jurisdiction then, as consequent CT5, a particular rate is to be used to calculate an amount of resource due to that particular domain.
Referring again to
At step 304, the filing engine electronically configures parameters in accordance with the initial setup by one or more users. For example, this step may include modifying a user profile for the one or more users by populating the user profile with identifying information submitted by the one or more users. Additionally, or alternatively, this step may include inputting any other suitable information useful for a user profile and/or useful for the initial setup of the automated electronic data sheet generation and submission workflows described in more detail below.
At step 306, the filing engine electronically receives, over a computer network and from multiple different remote systems, electronic records recording interchanges in which one or more additional users participated.
At step 308, the filing engine electronically extracts data concurrently from the electronic records.
At step 310, the filing engine electronically routes the data through a workflow control platform.
At step 312, the filing engine electronically validates the data as accurate a first location controlled by the workflow control platform.
At step 314, the filing engine, based on the validated data, electronically executes determinations concurrently for generating electronic data sheets associated with resources to be electronically filed with one or more domains.
At step 316, the filing engine electronically generates the electronic data sheets associated with the resources concurrently at least in part by automatically populating the electronic data sheets with values resulting from the determinations.
At step 318, the filing engine electronically files the generated electronic data sheets with the one or more domains automatically such that further contacting the one or more users for electronically filing the generated electronic data sheets is avoided beyond the initial setup.
At step 322, the filing engine receives user information for electronically filing or updating an electronic data sheet that corresponds to a user and a domain.
At step 324, the filing engine maintains a record of past electronic activities by the user.
At step 326, the filing engine electronically receives interchange data associated with interchanges executed by the user.
At step 328, the filing engine automatically generates the electronic data sheet for the user based on the user information and the interchange data.
At step 330, the filing engine electronically triggers a notification when a threshold is met for approaching a pre-allocated amount of resources.
At step 332, the filing engine electronically issues an alert to electronically request additional resources from the user in response to resource amounts to be transmitted having exceeded an amount of resources received from the user.
At step 334, the filing engine electronically determines an estimated amount of resources to be transmitted based on an analysis of the interchange data associated with the interchanges executed by the user.
At step 336, the filing engine electronically adjusts an electronic value for the user according to a remittance risk calculation.
The computer system 495 and the computer system 490 have similarities, which
The computer system 495 includes one or more processors 494. The processor(s) 494 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 as 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 processors 494 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”.
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 specialized machines, or specific specialized 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.
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 495, or the computer system 490, are not intended to be exhaustive. Rather, they are representative, for highlighting essential components that can be used with embodiments.
The computer system 495 also includes a system bus 412 that is coupled to the processor(s) 494. The system bus 412 can be used by the processor(s) 494 to control and/or communicate with other components of the computer system 495.
The computer system 495 additionally includes a network interface 419 that is coupled to system bus 412. Network interface 419 can be used to access a communications network, such as the network 188. Network interface 419 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.
The computer system 495 also includes various memory components. These memory components include memory components shown separately in the computer system 495, plus cache memory within the processor(s) 494. Accordingly, these memory components are examples of non-transitory machine-readable media. The memory components shown separately in the computer system 495 are variously coupled, directly or indirectly, with the processor(s) 494. The coupling in this example is via the system bus 412.
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 495, 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 processors 494 of a host computer system such as the computer system 495 or the computer system 490, can cause the host computer system to perform operations according to embodiments. The instructions may be implemented by computer program code for carrying out operations for aspects of this document. 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.
The memory components of the computer system 495 include a non-volatile hard drive 433. The computer system 495 further includes a hard drive interface 432 that is coupled to the hard drive 433 and to the system bus 412.
The memory components of the computer system 495 include a system memory 438. The system memory 438 includes volatile memory including, but not limited to, cache memory, registers and buffers. In embodiments, data from the hard drive 433 populates registers of the volatile memory of the system memory 438.
In some embodiments, the system memory 438 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, an Operating System (OS) 450, libraries 460, frameworks/middleware 468 and application programs 470, which are also known as applications 470. Other software architectures may include less, 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 468.
The OS 450 may manage hardware resources and provide common services. The libraries 460 provide a common infrastructure that is used by the applications 470 and/or other components and/or layers. The libraries 460 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 450. The libraries 460 may include system libraries 461, such as a C standard library. The system libraries 461 may provide functions such as memory allocation functions, string manipulation functions, mathematical functions, and the like.
In addition, the libraries 460 may include API libraries 462 and other libraries 463. The API libraries 462 may include media libraries, such as libraries to support presentation and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG. The API libraries 462 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 491. The API libraries 462 may further include database libraries, for instance SQLite, which may support various relational database functions. The API libraries 462 may additionally include web libraries, for instance WebKit, which may support web browsing functionality, and also libraries for applications 470.
The frameworks/middleware 468 may provide a higher-level common infrastructure that may be used by the applications 470 and/or other software components/modules. For example, the frameworks/middleware 468 may provide various Graphic User Interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks/middleware 468 may provide a broad spectrum of other APIs that may be used by the applications 470 and/or other software components/modules, some of which may be specific to the OS 450 or to a platform.
The application programs 470 are also known more simply as applications and apps. One such app is a browser 471, which is a software that can permit the user 192 to access other devices in the internet, for example while using a Graphic User Interface (GUI). The browser 471 includes program modules and instructions that enable the computer system 495 to exchange network messages with a network, for example using Hypertext Transfer Protocol (HTTP) messaging.
The application programs 470 may include one or more custom applications 474, made according to embodiments. These can be made so as to cause their host computer to perform operations according to embodiments disclosed herein. Of course, when implemented by software, operations according to embodiments disclosed herein may be implemented much faster than may be implemented by a human mind if they can be implemented in the human mind at all; for example, tens or hundreds or millions of such operations may be performed per second according to embodiments, which is much faster than a human mind can do. Such speed of operations, and thus the use of such computing systems and networks, are integral to the embodiments described herein because such operations would be practically useless unless they are able to be applied to hundreds or thousands of computer network clients simultaneously or concurrently across computer networks and to the vast volumes of data that change in real-time provided by such computer network clients. Implementing a practical application of the embodiments described herein to hundreds or thousands of computer network clients simultaneously or concurrently across computer networks on which they operate and to the vast volumes of data that change in real-time provided by such computer network clients is impossible to do in the human mind.
Other such applications 470 may include a contacts application, a word processing application, a location application, a media application, a messaging application, and so on. Applications 470 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 such as IOS™, ANDROID™, Win phones, or other mobile operating and/or portable computing systems. The applications 470 may use built-in functions of the OS 450, of the libraries 460, and of the frameworks/middleware 468 to create user interfaces for the user 192 to interact with.
The computer system 495 moreover includes a bus bridge 420 coupled to the system bus 412. The computer system 495 furthermore includes an input/output (I/O) bus 421 coupled to the bus bridge 420. The computer system 495 also includes an I/O interface 422 coupled to the I/O bus 421.
For being accessed, the computer system 495 also includes one or more Universal Serial Bus (USB) ports 429. These can be coupled to the I/O interface 422. The computer system 495 further includes a media tray 426, which may include storage devices such as CD-ROM drives, multi-media interfaces, and so on.
The computer system 490 may include many components similar to those of the OSP 198, as seen in
The computer system 490 further includes peripheral input/output (I/O) devices for being accessed by a user more routinely. As such, the computer system 490 includes a screen 491 and a video adapter 428 to drive and/or support the screen 491. The video adapter 428 is coupled to the system bus 412.
The computer system 490 also includes a keyboard 423, a mouse 424, and a printer 425. In this example, the keyboard 423, the mouse 424, and the printer 425 are directly coupled to the I/O interface 422. Sometimes this coupling is wireless or may be via the USB ports 429.
In this context, “machine-readable medium” 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 thumb drive, a hard disk, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, an Erasable Programmable Read-Only Memory (EPROM), an optical fiber, a portable digital versatile disc (DVD), 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 processors 494.
The term “machine-readable medium” 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 or otherwise generic, non-programmed machine into a specialized particular machine programmed to carry out the described and illustrated functions in the manner described.
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.
Similarly, as further shown in this figure, memory 434B may further include resource content 436B, customer data 444B, generated data 452B, and documents 458B. Moreover, in terms of composition relationships, resource content 436B may further include validation rules 438B, mapping data 440B, and filing content 442B. User data 444B may further include an interchange request 446B, batch information 448B, and user details 450B. Generated data 452B may further include validation results 454B and calculated report data 456B. Lastly, documents 458B may further include one or more instances of a data sheet 460B and one or more interchange records 462B.
Generally speaking, workflow as a service 420B may orchestrate one or more operations to be performed by the remaining functional components shown within processor 418B. Moreover, these functional components may generally map to, or correspond to, one or more steps of method 300. For example, extractor 422B may perform step 308 of electronically extracting data concurrently from the electronic records. Similarly, data router 424B may perform step 310 of electronically routing the data through a workflow control platform, which may be orchestrated or managed by workflow as a service 420B. Validator 426B may perform step 312 of electronically validating the data as accurate at a first location controlled by the workflow control platform. When performing step 312, validator 426B may reference validation rules 438B and produce validation results 454B. Calculator 428B may perform step 314 of electronically executing determinations concurrently for generating electronic data sheets associated with the resources to be electronically filed with one or more domains. When performing step 314, calculator 428B may reference one or more of resource content 436B, user data 444B, generated data 452B, and documents 458B. Form generator 430B may perform step 316 of electronically generating the electronic data sheets associated with the resources concurrently at least in part by automatically populating the electronic data sheets, including one or more instances of data sheet 460B, with values resulting from the determinations. Lastly, form filer 432B may perform step 318 of electronically filing the generated electronic data sheets with the one or more domains automatically such that further contacting the one or more users for electronically filing the generated electronic data sheets is avoided beyond the initial setup.
Operational Examples—Use CasesThe above-mentioned embodiments have one or more uses. Aspects presented below may be implemented as was described above for similar aspects. (Some, but not all, of these aspects have even similar reference numerals.)
As an example of a use case, there is a need for managing and processing data associated with resources that obligates a person or entity to pay another entity, such as a government authority (e.g., a tax authority) for certain relationship instances or interchanges (e.g., transactions that occurred in a jurisdiction, marketplace, online, in a specific business sector, involving certain products or services, and so on). One such type of resource may be a tax, such as a value added taxation (VAT), sales tax, or other type of tax. In the example use case of VAT, the electronic calculation of the correct VAT and electronic preparation for filing VAT registration documents and VAT tax returns for thousands upon thousands of transactions for hundreds or thousands of sellers is complex and laborious. Such a seller may be a customer or client of an OSP (referred to herein as a customer/seller or client), such as OSP 598, and access the OSP 598 via client device 502 over network 188. Before an OSP customer/seller can file tax returns to meet tax compliance requirements for their activities, registration of the customer/seller is often required, upon which an identifier such as a customer number, registration number, or account number is issued. Once the customer number, for example, is issued, the customer/seller may then file tax returns with one or more corresponding tax authorities (e.g., tax authority 581, tax authority 582, . . . ) represented by the set of tax authorities 580.
The OSP 598 may be configured as part of an example adaptive registration system (ARS) 594 to provide an automated electronic service for processing and generating a registration document, represented by tax registration 585, to be submitted to, for example, a tax authority (e.g., tax authority 581) that requires it before being able to electronically file a tax return associated with resources, such as VAT taxes. Such processing and generating the tax registration may be performed by the registration engine 586 for hundreds or thousands of clients via hundreds or thousands of remote client devices 502 over network 188 simultaneously or concurrently (which is impossible to do in the human mind) to provide more accurate and efficient computer network operations for electronic document generation for various systems on the network, including the client devices and devices of the set of tax authorities 580, thus improving the technology of computer networks and the technology of electronic document generation.
In particular, Such processing and generating the tax registration performed by the registration engine 586 for hundreds or thousands of clients via hundreds or thousands of remote client devices 502 over network 188 simultaneously or concurrently increases the speed at which the electronic services are provided (as opposed to the devices waiting for them to be performed serially). This reduces data flows over the computer network by avoiding the client devices having to resend requests to perform the electronic services and provide updated data due to lag times that would otherwise be experienced by the client devices between when the original request was sent and when the electronic operations are actually able to be performed. Thus, the systems and methods described herein for automated actions for automated preparation and submission of electronic registration improve the functioning of computer or other hardware, such as by reducing the processing, storage, and/or data transmission resources needed to perform various tasks, including preparation and submission of electronic registration, thereby enabling the tasks to be performed by less capable, capacious, and/or expensive hardware devices, and/or be performed with less latency, and/or preserving more of the conserved resources for use in performing other tasks or additional instances of the same task.
Operational examples and sample use cases are possible where the attribute of an entity in a dataset, such as dataset 535, is any one of: the entity's name; type of entity; a physical location such as an address; a contact information element; transactions of the entity; a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify the entity; an identifier of a specific source of revenue received for a transaction of the entity; characteristics of transactions of the entity; licensure and/or or registration of the entity and/or products or services the entity produces, sells, stores and/or transfers; business registrations of the entity; documents and/or images of the entity; governmental documents of the entity; government issued identification (ID) documents of the entity or a person associated with the entity; products or services produced, sold, stored and/or transferred by the entity; types of products or services produced, sold, stored and/or transferred by the entity; a location to which products are sent, shipped or transferred; a location from which products are received; a location of a property owned by the entity; a location of a property owned by the entity within a particular region of other domain; 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; and so on. Different resources may be produced in such instances, and so on.
An identifier component of the tax registration engine 586 may create or associate a business identifier, customer number, account number, or other customer identifier, etc. The customer identifier can be used to search for customer information to enable the automated registration process. For example, the identifier component may electronically obtain from client device 502 or another source, via network 188, a pre-existing entity identifier of the client that had been previously used by an electronic system of at least one of the tax authorities 580 to identify the client. The identifier component may then electronically associate the pre-existing entity identifier with the client. A Docufetch component of the tax registration engine 586 may then, using at least the entity identifier, perform automated actions via network 188 to electronically collect support content from the Internet or other sources, via network 188, regarding the client to facilitate automated preparation of the tax registration 585.
As one example, such support content may be collected from public/government web sites. For example, the Docufetch component may be configured to search for customer information, based on known information about the customer, whether provided by the customer manually or obtained by the activities of the ARS 594. In some embodiments, the Docufetch component may employ web crawlers to go through government websites, searching for customer information, for example, by using a customer identifier. The user, adaptive UI 504 and webcrawler of the Doccufetch component may, for example, work together to download documents and electronically pull documents into the OSP 598. The Docufetch component may also use web application programming interfaces (APIs). In some embodiments, user input may indicate where the customer or associated entity or business is from or located. Based on this user input, the digital tax rules 570 may be electronically consulted to automatically choose which web site or data source site it has to interact with to obtain certain information for the tax registration process. In various embodiments, the digital tax rules 570 may be electronically consulted based upon modifiable workflow configurations.
A translator component may also be utilized by the tax registration engine 586 to translate documents and/or data related to the tax registration 585 to be in a language and/or format readable, compatible or otherwise acceptable by an applicable tax authority and/or the tax registration engine 586. An information extractor component of the tax registration engine 586 may then electronically identify data from the support content relevant to the electronic registration and electronically extract the identified data from the support content in response to electronically identifying the data by the identifier component. For example, once documents have been fetched by the Docufetch component, which may be based on the user input and consulting the digital tax rules 570, the system uses appropriate technology, such as, for example optical character recognition (OCR), a portable document format (PDF) editor, etc., to extract information. Once information is extracted, the data may be returned or processed in a format that can be consumed by users for a particular purpose or used by the ARS 594 for the next process.
In an example embodiment, once a document is in the OSP 598 (e.g., saved in memory 538), depending on the document, or format (which can be dictated by language, jurisdiction, purpose, technology (PDF format, MS Word format, particular image format, etc.) and so on, information is extracted from the document in accordance with the type of document and/or format. In some embodiments, existing technology may be used, such as OCR, or other available character or object recognition technology (e.g., OnFido), to scrape content from a document to pull necessary information and prepopulate a UI questionnaire, registration form, etc. In turn, the extracted content may be configured into a specific format for a specific purpose, the ARS 594 being able to place the content in any number of formats. The registration engine 586 may then electronically verify the extracted data and electronically generate and/or electronically file or otherwise submit the tax registration 585 based on the extracted data.
It will be recognized that aspects of
Above the line 515, a computer system processor 595 is shown, which is used to help customers, such as a client associated with client device 502, with tax compliance. Further in this example, the computer system processor 595 is part of an OSP 598 that is implemented as a Software-as-a-Service (SaaS) provider, for being accessed by the client online. Alternately, the functionality of the computer system processor 595 may be provided locally to a user.
In embodiments, the client device 502 can be a device of a business, such as a seller of items, a reseller, a buyer, and so on. In this present case, the client device 502 is a device of an individual or business that sells goods or services. In such instances, the user of the client device 502 can be an employee, a contractor, or otherwise an agent of the business. In such cases the client device 502 can even be that of an online seller, but that is not necessary.
In a number of instances, the user of the client device 502 uses software applications and ERP technology to manage business activities, such as sales, resource management, production, inventory management, delivery, billing, and so on. Such software applications, and more, may be used locally by the user of the client device 502, or from an Online Processing Facility (OPF) 589 that has been engaged for this purpose by the user of the client device 502, and/or the client device 502. In such use cases, the OPF 589 can be a Mobile Payments system, a Point Of Sale (POS) system, an accounting application, an Enterprise Resource Planning (ERP) system or provider, an e-commerce provider, an electronic marketplace, a Customer Relationship Management (CRM) system, and so on.
To help with such complex determinations and solve such technical problems, the computer system processor 595 may be specialized device for tax compliance as disclosed herein. OSP 598 The OSP 598 processor thus implements tax registration engine 586 to electronically generate the electronic tax registration 585 based on application of the digital tax rules 570 to the extracted data. Other components of the OSP 598 may make the determinations of tax obligations and perform electronic preparation and sending of associated tax return document(s) to applicable tax authorities 580. The registration engine 586 can as described as an example instance of, or be part of, or be a separate component from, the filing engine 183 of
The OSP 598 may further store locally entity data, i.e., data of an entity associated with client device 502, any of which/whom may be a customer of OSP 598 and/or a seller or a buyer in a sales transaction in various embodiments. The entity data may include profile data of the customer and transaction data (e.g., including a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify the entity and/or support content) based on which a tax registration 585 may be performed and a determination of a tax obligation is desired. In the online implementation of
Digital registration rules are further implemented within the OSP 598. The registration rules can be part of digital tax rules 570 for use by the tax registration engine 586. As part of managing the digital tax rules, there may be continuous updates of the digital tax rules 570, by inputs gleaned from a set 580 of different tax authorities 581, 582, . . . . Updating may be performed by humans, or automatically by computers, and so on. As mentioned above, the number of the different tax authorities in the set 580 may be very large.
For a specific tax registration 585 and determination of a tax obligation, the OSP 598 may receive one or more datasets. A sample received dataset 535 is shown just below line 515, which can be similar to what was described for the dataset 135 of
In this example, the dataset 535 has been received because it is desired to perform a tax registration 585 for an entity associated with the client device 502. As such, the sample received dataset 535 has values that characterize attributes of the client (e.g., a seller) and possibly also buy-sell transactions. Accordingly, in this example the sample received dataset 535 has a value ID for an identity of the dataset 535 and/or the transaction. The dataset 535 may also have a value PE for a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify the client and perhaps also the name of the client device 502 or the user, which can be the seller making sales transactions, some online. The dataset 535 further has a value PD for relevant data of the client device 502 or the user, such as an address, place(s) of business, prior nexus determinations with various tax jurisdictions, and so on. The dataset 535 may also have a value SE for the name of a secondary entity, which can be the buyer and/or a recipient of goods or services. The dataset 535 may further have a value SD for relevant data of the secondary entity (the buyer and/or a recipient of goods or services), such as relevant, identification information entity-driven exemption status, and so on. The dataset 535 may have a value B2 for the sale price and/or value of the item or items sold, shipped and/or received.
The dataset 535 may further have a value RS that includes a unique identifier that contains or identifies information identifying or regarding a revenue source system for revenue received for the transaction. The dataset 535 may have fewer values or have additional values, as indicated by the dot-dot-dot in the dataset 535. These values may characterize further attributes, such as characteristics of goods or services sold, data identifying of or otherwise relating to a license or registration required for the transaction, a date and possibly also time of the transaction, and so on.
The digital tax rules 570 have been created so as to accommodate tax rules that the set 580 of different tax authorities 581, 582 . . . promulgate within the boundaries of their tax jurisdictions and workflow configurations and settings. In
Similarly with
In this example, a certain digital tax rule T_RULE6 575 is shown as identified and used, which is indicated also by the beginning of an arrow 588. Identifying may be performed responsive to the values of the dataset 535, which are shown as considered for digital tax rules 570 by arrows 571. For example, it can be recognized that a condition of the digital tax registration rule T_RULE6 575 is met by one or more of the values of the dataset 535. For instance, it can be further determined that automated actions to electronically collect one or more support content from the Internet or other sources regarding an entity associated with client device 502 are to be performed to facilitate automated preparation of the electronic registration document for the entity.
As such, the OSP 598 may perform the tax registration 585 with one or more of the applicable tax authorities in the set of tax authorities 580 via network 188. The OSP 598 may also file or otherwise send (or cause to be filed or sent) a corresponding tax return document (e.g., tax return 509) to one or more of the applicable tax authorities in the set of tax authorities 580 via network 188. The tax registration 585 can be produced by the OSP 598 applying the certain digital tax rule T_RULE6 575, as indicated by the arrow 588. In this example, the consequent of the identified certain digital tax rule T_RULE6 575 may specify to extract the data identified from support content in response to electronically identifying the data in the support content (e.g., relevant data identified in a collected electronic document), electronically perform the tax registration 585 based thereon, and so on.
The OSP 598 may then cause a notification to be transmitted. The notification can be about an aspect of the tax registration 585. In the example of
The notification can be transmitted to one of an output device and another device that can be the remote device, from which the dataset 535 was received. The output device may be the screen of a local user or a remote user (e.g., a screen of client device 502). The notification may thus cause a desired image to appear on the screen, such as within a Graphical User Interface (GUI) and so on. The other device may be a remote device, as in this example. In particular, the OSP 598 causes the notification to be communicated by being encoded as a payload 537, which is carried by a response 587. The response 587 may be transmitted via the network 188 responsive to the received request 584. The response 587 may be transmitted to the client device 502, to OPF 589, to one or more tax authorities 580, and so on. As such, the other device can be the client device 502, or a device of the OPF 589, or a screen of such devices. In this example the single payload 537 encodes the entire notification, but that is not required, similarly with what is written above about encoding datasets in payloads. Along with the aspect of the tax registration 585, it is advantageous to embed in the payload 537 the ID value and/or one or more values of the dataset 535. This will help the recipient correlate the response 587 to the request 584, and therefore match the received aspect of the tax registration 585 as the answer to the received dataset 535.
In an example embodiment, the client device 502, may have a certain application (not shown) which may, for example, be developed using a Software Development Kit (SDK) and may have a connector that is a plugin that sits on top of that certain application. The connector may be able to send and/or receive the details required for the service desired from the OSP 598, form an object or payload 534, and then send or push a request 584 that carries the payload 534 to the tax registration engine 586 via a service call. The tax registration engine 586 may receive the request 584 with the payload 534. The tax registration engine 586 may then apply digital tax rules 570 to the payload 534 to obtain, collect, extract, identify, associate and/or verify data; generate an electronic tax registration form or document; perform an electronic tax registration 585; determine a requested resource and/or form a payload 537 that is an aspect of such operations, the electronic tax registration 585 and/or the resource. The tax registration engine 586 may then push, send, or otherwise cause to be transmitted a response 587 that carries the payload 537 to the connector. The connector reads the response 587, and forwards the payload 537 to the certain application of the client device 502. The same or similar process may be performed by the tax registration engine 586 for electronically submitting the tax registration 585 to respective systems of the tax authorities 580.
An adaptive user interface (UI) 504 to the OSP 598 for processing registrations for registering with one or more of the tax authorities 580 or for filing a tax return may (e.g., tax return 579) be presented on the client device 502. In an example embodiment, before electronically generating the tax registration 585 based on the extracted data, the tax registration engine 586 electronically determines, based on the extracted data, whether to electronically present a query via the adaptive UI 504 for supplemental data regarding the entity associated with the client device 502 in order to facilitate automated preparation of the electronic tax registration 585. The tax registration engine 586 may automatically modify the adaptive UI 504 in response to the determination whether to electronically present a query via the adaptive UI 504 for the supplemental data. The tax registration engine 586 may electronically present the query via the adaptive UI 504 for the supplemental data. The tax registration engine 586 may then electronically receive the supplemental data over network 188 via the adaptive UI 504 in response to electronically presenting the query via the adaptive UI 504 for the supplemental data and electronically verify the supplemental data. The OSP 598 may also have an OSP internal adaptive UI that automatically changes or is modified for administrators of the OSP 598.
Referring now also to
The WFaaS component 592 manages and controls such systems of the OSP 598 for efficient and accurate operations, for organizing vast amounts of information concurrently and/or simultaneously, to process documents, and to set up and manage workflow processes. The WFaaS component 592 is also configured to concurrently and/or simultaneously manage and process data/information for a large number of clients for the purposes of preparing documents associated with registration for filing, for example, a VAT return, and any other processes related to the registration and return filing. The overall system of
The OSP 598 and associated WFaaS component 592 enable, via a scalable resource return filing system component 596, a scalable workflow platform and infrastructure to provide services such as tax registration, preparing tax documents, and filing such documents in an automated manner. The scalable resource return filing system component 596 may comprise, include, be implemented by and/or be part of the tax registration engine 586 of the OSP 598. In an example embodiment, the scalable resource return filing system component 596 is in operable communication with the WFaaS component 592. The use cases involving these services include providing direct and indirect tax compliance solutions with a tax authority, such as electronic VAT registration, electronic VAT returns, automatic filings, reconciliation reports and generating client reports. In some embodiments, the WFaaS component 592 functions as a technological toolbox to power the generation of registrations and returns, and the data associated with these processes, to facilitate the entire registration process and/or tax return filing process in an automated manner, as an example of a use case.
The WFaaS component 592 of the OSP 598 is configured to create workflows and implement how to mitigate failure events. In some embodiments, the WFaaS component 592 is configured to create, control, manage and enable the workflows. In some embodiments, the WFaaS component 592 enables the generation and management of documents and forms, such as a registration form based on one or more combinations of received client data, business related data, history of client data and activities within the OSP 598, to automate the process for generating registration forms and filing them with the proper external entity.
In some embodiments, machine learning techniques are utilized and improve upon the accuracy and speed at which registration documents, and other related documents are collected and processed. In various embodiments, the ARS 594 may comprise, include, be implemented by or be part of the tax registration engine 586, the OSP 598, the client device 502 and/or any other device, component or system depicted in
Although not all the components of a computer system are shown in
In some instances, in addition to typical data, signals and protocols, the request data (e.g., in request 584) may include the actual/original document, business identifier, etc., sent from the client device 502, and response data (e.g., in response 587) may include the parsed/extracted data from the documents (after the extraction by the ARS 594).
The OSP 598 also includes a memory 538 for storing documents and other data, which may include data provided by a user at the client device 502 and data extracted and/or processed by the ARS 594. The memory 538 also includes a set of digital tax rules that the WFaaS component 592 or tax registration engine 586 may consult or otherwise confer to make necessary decisions to update the adaptive UI 504 in real time or generate an accurate registration form, as an example.
The WFaaS component 592 may be configurable by administrators or other agents of the ARS 594 and control the workflows of the ARS 594 to manage the data collected, generated, and processed, and the process for generating a registration form. In embodiments, the WFaaS component 592, which may comprise or be part of the tax registration engine 586, may include or control an identifier component to create or associate a business identifier, customer number, account number, etc. The customer identifier can be used to search for customer information. The WFaaS component 592 may also include or control a Docufetch component that is configured to go through government websites, local sources and other sites and sources containing public or private records, and to search for and gather customer information using, for example, using a user interface and webcrawler. Documents may be downloaded into or retrieved by the OSP 598 to process via an information extractor of the OSP 598. The information extractor extracts data being searched about the customer and/or business/activities from documents downloaded from the Internet or other sources. The WFaaS component 592 may also include or control the a form generator of the OSP 598, which collates the customer information necessary to generate a form, and is also configured to automatically file the form with, for example, one or more of the tax authorities 580.
As another example use case, the primary entity 193 of
As shown, OSP 598 may further include a funding engine 522, which may further include a funding estimator 524, a ledger 526, risk logic 528, and a payment submission component 530. OSP 598 may also include an instance of memory 538, which may further include payment details 540 and the ledger 542. These various components will be discussed in more detail in connection with
Operational examples and sample use cases are possible where the attribute of an entity in a dataset is any one of: the entity's name; type of entity; a physical location such as an address; a contact information element; transactions of the entity; an identifier of a specific source of revenue received for a transaction of the entity; characteristics of transactions of the entity; licensure and/or or registration of the entity and/or products or services the entity produces, sells, stores and/or transfers; products or services produced, sold, stored and/or transferred by the entity; types of products or services produced, sold, stored and/or transferred by the entity; a location to which products are sent, shipped or transferred; a location from which products are received; a location of a property owned by the entity; a location of a property owned by the entity within a particular region of other domain; 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; and so on. Different resources may be produced in such instances, and so on.
It will be recognized that aspects of
Above the line 515, an OSP 598 is shown, which is used to help customers, such as a user, with tax compliance. Further in this example, OSP 598 is implemented as a workflow as a service provider, such as workflow as a service 420B, for being accessed by the user online. Alternately, the functionality of OSP 598 may be provided locally to a user.
The user may be standalone. The user may use a client device 502 that has features an adaptive UI 504, an software development kit 506, and/or a connector 508. Client device 502 may also feature memory 532, which can include a funding history and ledger 512, as discussed in more detail below in connection with
In a number of instances, the user, the secondary seller and/or the intermediary entity use software applications to manage their business activities, such as sales, resource management, production, inventory management, delivery, billing, and so on. The user, the seller, and/or the intermediary entity may further use accounting applications to manage purchase orders, reservations, bookings, sales invoices, refunds, payroll, accounts payable, accounts receivable, and so on. Such software applications, and more, may be used locally by the user or intermediary entity, or from an Online Processing Facility (OPF) 589 that has been engaged for this purpose by the user, the seller, and/or intermediary entity. In such use cases, the OPF 589 can be a Mobile Payments system, a Point Of Sale (POS) system, an Accounting application, an Enterprise Resource Planning (ERP) system or provider, an e-commerce provider, an electronic marketplace, a Customer Relationship Management (CRM) system, and so on. In some embodiments, the OPF may be, or be used by, the intermediary entity.
Businesses have tax obligations to various tax authorities of respective tax jurisdictions. 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, value-added tax, lodging 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.
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 country, of a state/province, of a municipality, 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 the tax obligations to the tax authority. These obligations include requiring the business to: a) register itself with the tax authority's tax 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 taxi agency, d) periodically prepare a form (“tax return 579”) that includes an accurate determination of the amount of the money owed to the tax authority as sales tax because of the sales transactions, e) file the tax return 579 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.
A technical 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 plain 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 must pay it to the tax authorities—if they 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 local authority 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. 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 be required to pay the difference, plus fines and/or late fees, because ignorance of the law is not an excuse. Further, one should note that sales taxes are considered trust-fund taxes, meaning that the management of a company can be held personally liable for the unpaid sales tax.
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.
First, some 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 or from the buyer's location.
Second, the various tax authorities assess different, i.e. 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 countries, regions, provinces/states, counties, cities, municipalities, special taxing jurisdictions, and so on. In fact, there are over different tax jurisdictions in the US alone, with many partially overlapping.
Third, in some instances no 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.
Fourth, in some instances no tax is due at all because of who the individual buyer is. For example, certain entities are exempt from paying sales tax on their purchases, so 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.
Fifth, it can be difficult to determine which tax authorities a seller owes 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 region, state/province or even a city may set its own nexus rules for when a business is considered to be “engaged in business” with it, and therefore that business is subject to registration and collection of sales taxes. These nexus rules may include different types of nexus, such 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.
Even where a seller might not have reached any of the thresholds for economic nexus, a number of tax jurisdictions 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 respective tax jurisdiction have an obligation, instead of the seller, to collect sales tax on behalf of their sellers, and remit it to the respective tax authority. The situation becomes even more complex when a seller sells via such an intermediary.
To help with such complex determinations and solve such technical problems, OSP 598 may include a specialized device for tax compliance as disclosed herein. OSP 598 may have one or more processors 595 and memory 540, for example, as was described for the computer system 195 of
OSP 598 may further store locally entity data, which may include user data, such as customer data and/or seller data. 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
For a specific determination of a tax obligation, OSP 598 may receive one or more datasets. A sample received dataset 535 is shown just below line 515, which can be similar to what was described for the dataset 135 of
In this example, the dataset 535 has been received because it is desired to determine any tax obligations arising from a corresponding buy-sell transaction. Accordingly, in this example the sample received dataset 535 has a value ID for an identity of the dataset 535 and/or the transaction. The dataset 535 also has a value PE for the name of the seller or the user, which can be the seller making sales transactions, some online. The dataset 535 further has a value PD for relevant data of the seller or the user, such as an address, place(s) of business, prior nexus determinations with various tax jurisdictions, and so on. The dataset 535 also has a value SE for the name of the secondary entity, which can be the buyer. The dataset 535 further has a value SD for relevant data of the secondary entity, entity-driven exemption status, and so on. The dataset 535 has a value B2 for the sale price of the item sold.
The dataset 535 further has a value RS that includes a unique identifier that contains or identifies information identifying or regarding a revenue source system for revenue received for the transaction and the location(s) of one or more properties being rented on the system. The dataset 535 may fewer values or have additional values, as indicated by the dot-dot-dot in the dataset 535. These values may characterize further attributes, such as characteristics of data identifying of or otherwise relating to a license or registration required for the transaction, a date and possibly also time of the transaction, and so on.
The digital tax rules 570 have been created so as to accommodate tax rules that the set 580 of different tax authorities 581, 582 . . . promulgate within the boundaries of their tax jurisdictions and to indicate when and how to prepare and file corresponding tax return 579 documents. In
Similarly with
In this example, a certain digital tax rule T_RULE6 576 is shown as identified and used, which is indicated also by the beginning of an arrow 578. Identifying may be performed responsive to the values of the dataset 535, which are shown as considered for digital tax rules 570 by arrows 571. For example, it can be recognized that a condition of the digital tax rule T_RULE6 576 is met by one or more of the values of the dataset 535. As such, OSP 598 may produce the tax return 579 document, which is akin to producing the electronic data sheet 179 of
In an example embodiment, OSP 598 causes an additional payment alert 516, a credit threshold notification 517, and/or an estimated tax payment amount 518 to be transmitted. Consistent with method 321, discussed above in connection with
Upon receiving transaction information from external marketplace 602 or file upload 608, an extractor studio 604 may extract relevant data for subsequent processing throughout the remainder of system 600. Generally speaking, extractor studio 604 may extract more relevant data from less relevant data and/or discard irrelevant data for the purposes of generating electronic data sheets. Extractor studio 604 may be configured with extractor tools to extract corresponding data. The functionality of extractor studio 604 reflects the reality that not all of the bits of information uploaded from external marketplace 602 and/or file upload portal 608 may be relevant or necessary for the performance of method 300 and/or method 321 using system 600. Accordingly, extractor studio 604 may selectively extract only those bits of information that are (sufficiently) relevant, useful and/or necessary for the purposes of performing method 300 and/or method 321.
After the performance of extraction, the next instance of higher-level functionality that may be performed by system 600 corresponds to data routing. Data routing may be performed by data router 606, data synchronizer 614, and/or ingress-API 616. Generally speaking, data router 606 may route incoming data, after the performance of extraction, such that the data is appropriately forwarded to a target or recipient subcomponent within system 600. In particular, data router 606 may determine whether incoming data will be properly routed to a remainder of system 600 or, instead, whether such data is more properly routed elsewhere (e.g., elsewhere within OSP 598). Data synchronizer 614 may synchronize the release of data at one or more predetermined schedules to further optimize performance. Accordingly, data synchronizer 614 perform a step 607, a step 609, and/or step 617, as further shown in this figure, which help to ensure that data is released and/or routed according to one or more schedules established by data synchronizer 614. Furthermore, as shown, at step 613, data synchronizer 614 can upload corresponding data to a cloud data storage bucket 618, which may be associated with an ingress-API 616.
For simplicity and ease of discussion, the diagram shown in
As further shown in this figure, data layer 622 may include an invoice API 624, a batch API 626, a validation API 628, a tax workflow API 630 for registrations, a report data API 634, and/or a tax workflow API 636 for filing periods. Invoice API 624 may provide an interface for inputting, parsing, and/or referencing corresponding invoices. Batch API 626 may provide an interface for identifying and/or processing batches of information, such as batches processed in parallel. Report data API 634 may provide an interface for reporting one or more instances of generated or calculated data to an end-user or customer, as discussed in more detail below. Tax workflow API 630 may provide an interface for facilitating the registration of users with system 600. Tax workflow API 626 may provide an interface for identifying, calculating, monitoring, and/or reporting corresponding windows of time associated with tax reporting periods.
The remaining subcomponents shown within
After the process of appropriately routing data, as further discussed above, system 600 may proceed to perform data validation, which can be discussed in more detail in connection with
One of the improvements associated with system 600 includes improvements associated with scalability and/or parallel processing. These improvements may be facilitated by the “batch” subcomponents shown within
In particular, in response to validation process 652 receiving the start process command from batch-validation-process-handler 650, validation process 652 may trigger validation process handler 654, at step 637, to get items in a batch, to get corresponding obligations at step 641, and to forward these to validation processor 656, which may furthermore retrieve or extract the corresponding data from cloud storage at step 643, thereby generating tax content 660. Validation process handler 654 may furthermore, at step 639, create a validation outcome, at step 639, which may be forwarded to validation API 658. Upon the completion of the validation process, as step 629, batch-validation-process-complete-handler 648 may forward the corresponding notification to generic orchestration handler 644, which may furthermore notify workflow as a service system 642, thereby enabling the subsystem to proceed to the next instance of high-level functionality associated with system 600, as discussed further below.
After data validation is performed by system 600, the next instance of high-level functionality associated with system 600 according to the workflow shown in these diagrams is form generation. As further shown in
The remainder of
More generally, it can be helpful if the reconciliation report specifies amounts of multiple underlying transactions on which at least one of the values from the values automatically populated into the tax returns or electronic data sheets is based. As described above, these underlying transactions may not be specified within the tax returns or electronic data sheets themselves. Accordingly, the reconciliation reports may enable a more complete audit or inspection procedure to be performed.
As shown,
In contrast to the reconciliation report associated with
In particular, service bus process 906 may initiate a timer for detecting whether a batch validation procedure has timed out at step 922. Subsequently, at step 924, service bus process 906 may retrieve obligations from service bus handler 908 using get obligations handler 938. Alternatively, if the process has timed out, then at step 934, service bus process 906 can publish the fact that the process completed in a stage of failure, which can furthermore be reported to validation service bus handler 918.
At step 924, service bus process 906 can retrieve obligations using get obligations handler 938, resulting in the successful retrieving of obligations. The successful retrieving of obligations can trigger the step of getting batch entries at step 926 using get batch entries handler 940. At step 928, service bus process 906 can publish a message for every entry of the batch entries using validation processor 942. In the case of a single invoice that has been completed, the result can be stored at step 936. Alternatively, if more than a single invoice is being processed then service bus process 906 can check that validation of all corresponding invoices and/or items of data has been successfully completed at step 930. In that case, service bus process 906 can publish a notification that the validation process is completed at step 932, and this notification can be reported to validation service bus handler 918, which can furthermore share this information with shared workflow service bus command handler 920. Shared workflow service bus command handler 920 can notify orchestration layer 902 of the successful completion of the validation of this batch of information. Orchestration layer 902 can, at step 912, notify the result of validating the batch, such as by referencing report data API 672 shown in
At step 1046, ingress data queue processor 1014 may download the data from ingress cloud storage subcomponent 1012. Ingress data queue processor 1014 may subsequently call, at step 1048, invoice API 1016. Invoice API 1016 may provide a programming interface for referencing and parsing data from corresponding invoices. Similarly, at step 1050, ingress data queue processor 1014 may create a batch of corresponding data for processing as a batch. Accordingly, at step 1050, ingress data queue processor 1014 can send an instruction to start the business process management event to orchestration handler 1020. In response, orchestration handler 1020 can, at step 1054, forward the instruction to start the business process management event to orchestration layer 1022, which can furthermore, at step 1036, start an external task, as detected by orchestration task listener 1024 at step 1056. Orchestration task listener 1024 can, in response, start the validation process that was further discussed above at step 1058, by notifying validation processor 1026, which can furthermore, at step 1060, forward an item of validation data to validation API 1030. As further shown in this figure, at step 1064 the result of performing validation procedures can be saved, and at step 1066, the results of the validation procedures can be sent to validation processor 1026. At step 1068, validation processor 1026 can forward the validation result to orchestration handler 1020, which can furthermore forward the validation result, at step 1070, to orchestration layer 1022. Moreover, as further shown in this diagram, in order to perform the validation procedures, validation API 1030 can retrieve, at step 1062, the corresponding data to be validated.
Diagram 1100 further illustrates how OSP 1116 can include a processor 1118 as well as memory 1134. When properly configured, such as by retrieving memory instructions from memory 1134, processor 1118 can implement a workflow as a service 1120, an extractor 1122, a data router 1124, a validator 1126, a calculator 1128, a form generator 1130, and/or a form filer 1132. Form filer 1132 can file corresponding tax returns with one or more tax authorities 1164, as shown in diagram 1100. Those having skill in the art will recognize that each one of the subcomponents shown within processor 1118 in diagram 1100 has a corresponding or parallel subcomponent within the workflow of
For completeness,
By way of illustrative example, if system 600 currently operates 64 parallel courses (capable of processing approximately 13,000 sellers or tax returns, and 16-20 million transactions in a span of approximately 3-4 hours), any one of the components of system 600, such as the extractor, data router, validator, calculator, form generator, form filer, etc., may be multiplied to increase the number of parallel courses that can be operated. In some embodiments, a component of system 600 is multiplied, and in some embodiments the entirety of system 600 can be multiplied, as shown in
In addition to the overall discussion of system 600 and the corresponding workflow of
From step 1302, method 1300 may proceed to a decision step 1304, at which point system 600 may check a ledger for whether funding or credit is available to cover the projected tax liability calculated at step 1302. This may correspond to the second part of the first stage of method 1300, which is based on the projected tax liability as a rough estimate rather than the more exact and accurate calculation that can be prepared and reported at the end of a tax reporting period. At decision step 1304, the reference to funding can refer to funding that (i) system 600 knows the user already possesses and can submit readily and/or (ii) funding that the user has already submitted to system 600 and/or an intermediary in escrow such that the funding is reserved safely and can be used to cover any future tax liabilities corresponding to the projected tax liability. Additionally, or alternatively, the reference to credit at decision step 1304 can refer to credit that system 600 has, when enhanced with risk-reduction intelligence, ascertained or evaluated as applicable to the user based on one or more items of evidence indicating credit worthiness, as discussed in more detail below. In various examples, instances of funding and/or credit can be combined, as appropriate or desired, to determine whether a user will be expected to appropriately cover projected and/or exactly calculated tax liabilities.
As a simplified example for illustration purposes, an amount of funding of $10 and an amount of credit of five dollars can be combined for a total available amount of $15 which can create a delta of $5 in a scenario where the projected tax liability at step 1302 is $20. In various examples, the risk threshold of step 1318 can correspond to, be the same as, and/or be proportional to an amount of credit ascertained as applicable to a particular user based on one or more items of evidence indicating credit worthiness. Accordingly, in this example, the risk threshold would correspond to $5 greater than the amount of funding that the user has already identified in escrow and/or savings, thereby creating a risk threshold of $15, which is exceeded by the projected tax liability of $20, as discussed above. Those having skill in the art will understand that this simplified example uses relatively simple and static rules or values, and more sophisticated versions of the risk-reduction technology may allocate or assign credit on a more dynamic basis.
If the decision is no at decision step 1304, then at step 1318, an internal notification can be transmitted indicating that the risk exceeds a corresponding threshold. This internal notification can also optionally be transmitted to the user as well for informational purposes.
Returning to the main branch of method 1300 in this flow diagram, from decision step 1304 method 1300 may proceed to decision step 1306, which may correspond to the beginning of the second stage of this overall process. In contrast to the first stage described above, at which point projected tax liabilities were calculated as a rough and/or preliminary calculation, the second stage can occur later in time, such as at the end of a tax reporting window of time, at which point system 600 may need to calculate the exact liability for a return using exact amounts for all associated transactions. Accordingly, at decision step 1306, system 600, when enhanced with appropriate intelligence corresponding to method 1300, can calculate the exact tax liability for a return and then decide whether this exact amount can be satisfied with funding and/or credit. As described above, in this example system 600 may provide credit to the end-user at the first stage of method 1300 as well as the second stage, but in other examples system 600 may only provide the option of credit to the end-user at the first stage. If the answer is yes at decision step 1306, then method 1300 may proceed to a step 1314, at which point system 600 may reserve the appropriate funds and allocate them to a specific return for filing. Subsequently, at step 1316, system 600 may pay the exact tax amount with the corresponding filing of a tax return. Further details of preparing and filing tax returns are discussed above in connection with
If the decision is no at decision step 1306, then method 1300 may proceed to step 1308, at which point system 600 may transmit a notification to the customer with a request for funding. At step 1310, the customer may add funds, if available, in order to complete the process of preparing and filing a corresponding return with appropriate payment. Accordingly, from step 1310, method 1300 may proceed again to step 1316, as discussed above. Afterward, method 1300 may end as shown.
In particular, diagram 1400 illustrates how funding engine 1422 within an OSP 1407 can, through one or more instances of response data 1414 and/or request data 1416, maintain a funding history and/or ledger 1402. Funding history and/or ledger 1402 may provide a ledger or other record that keeps track of how much funding a user or customer has provided in escrow and/or to a savings pool for the purposes of method 1300. Optionally, funding history and/or ledger 1402 may also provide a record of prior transactions and/or other instances of customer behavior, which can be useful when assessing the credit worthiness of the customer and/or assessing how much credit to extend the customer, which can facilitate the goal of avoiding contacting or disturbing the customer when making minor payments, as further discussed above.
In view of the above, funding engine 1422 may include another instance of funding history and/or ledger 1402, in the form of a ledger 1426, which resides as a copy within funding engine 1422. Similarly, funding engine 1422 may extract, from funding history and/or ledger 1402, data indicating customer transactions 1404, one or more records of past history of customer behavior 1408 and/or data indicating or describing one or more interactions with customers such as a history of behavior. Of course, those having skill in the art will understand that customer transactions 1404 and/or past history of customer behavior 1408 may potentially overlap partially or entirely.
From customer transactions 1404 and/or past history of customer behavior 1408, funding engine 1422 may implement risk logic 1428 that generates one or more outputs, consistent with method 1300, as described above. These outputs may include updated projected tax liabilities in real-time 1406, which can be calculated and/or estimated at step 1302 of method 1300. Additionally and/or alternatively, risk logic 1428 may generate, based on one or more of the inputs shown, a dynamic adjustment of how large of an overage will be handled from the pool 1410. This output can correspond to a credit worthiness assessment that establishes an amount of credit available to the customer, which can correspond to the risk threshold of step 1318 within method 1300, as discussed above. Additionally and/or alternatively, risk logic 1428 can generate an output in the form of an indication 1413 of how much to borrow against the pool to keep the customer current on tax liability. Thus, this latter output can correspond to a scenario where the decision is yes at decision step 1304, the decision is yes due to the availability of credit that was previously ascertained or assigned to the customer based on the funding and risk algorithm executed at step 1302 of method 1300. In other words, if the user has sufficient credit with which to cover exact tax liabilities, then this credit can be actually used or leveraged, in the form of indication 1413 shown in
In the case that there are not sufficient funds, even in combination with credit, to cover projected tax liabilities and/or exact tax liabilities, then funding engine 1422 can reference or issue one or more funding requests 1434 in order to request appropriate resources from the end-user. Additionally, or alternatively, if sufficient funds are obtained, and/or if a partial payment is desired or instructed, then a payment submission component 1430 within processor 1420 may submit appropriate payment to a tax authority 1436. For completeness, diagram 1400 also illustrates how OSP 1407 may include an instance of memory 1438, which may further record and/or store payment details 1440 and/or another copy of the corresponding ledger 1442.
-
FIG. 15 is a sample view of a UI 1500 for OSP 598 presented to a user showing an identification document uploaded by the user for verification of the user's identity in a process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return according to an embodiment of the present disclosure. In various example embodiments, UI 1500 may comprise or be part of the adaptive UI 504 and the description of UI 1500 will be in conjunction with also referring toFIG. 5A .
Shown displayed on UI 1500 is an image of an example scanned and uploaded identification document 1502 (e.g., a passport) resulting from the user following the process to do so initiated by selection of a UI element of Adaptive UI 504. In an example embodiment, if the scan of the identification document 1502 is blurry, illegible or otherwise deficient, OSP 598 detects the deficiency (e.g., by not being able to read the document) and prompts via UI 1500 for a new scan, and the feedback is provided in real time. OSP 598 will first resolve the deficiency issue to correctly identify the customer, before the UI 1500 updates with the next step of the registration process.
In another example, instead of a passport, an automatic download of a trade register fails, and the adaptive UI 504 is updated to prompt the customer with additional questions related to the trade register. The trade register may have been provided by the customer or it may have been downloaded as part of the process implemented by a Docufetch component of the OSP 598. The updating of the adaptive UI 504 occurs in real time to request the information OSP 598 needs to proceed to the next step in the tax registration process. As the data is verified, the data is processed by the tax registration engine 586 for storage and to be later retrieved for generating the registration form. The controls and instructions for this operation may be modified, configurable and regulated by the WFaaS component 592. Other documents may be processed and may in some instances comprise content that is electronically retrieved from websites as public information, such as from public/government web sites.
In an example embodiment, the digital tax rules 570 may be electronically consulted by the tax registration engine 586 to decide what the ARS 602 does next and how to update the adaptive UI 504. For example, the digital tax rules 570 being electronically consulted by the tax registration engine 586 may result in the following instructions being executed: first retrieve business document; then check/verify data about the customer based on the business document; and then check/verify customer data provided via adaptive UI 504 and existing customer data stored by the OSP 598. Each of the preceding steps may have a number of processes and flows before the next step is iterated, some or all of which may be modified, configured and regulated by the WFaaS component 592.
In an example embodiment, UI 1600 may appear or be made available (e.g., by selecting the “Registrations” tab) when an upload document task, for which an example is shown in UI 1500 of
UI 1700 is an example of a user interface displaying content prepared by the OSP 598 before a registration form is generated. For example, the content displayed in UI 1700 may be that which was extracted, by an information extractor of the OISP 589, from one or more documents obtained by the Docufetch component of the OSP 598 from external sources, internal sources, and/or one or more documents uploaded by the user via the adaptive UI 504. In the present example, shown is company information 1702 extracted from a business registration form either uploaded by the user or obtained by the Docufetch component of the OSP 598 from a particular public web site of public/government web sites based on the business identifier input by the user to an input field of the adaptive UI 504. Shown is selectable UI element 1704 which the user may select to edit or add to the company information 1702.
Also shown is directors information section 1706, which displays director information extracted from a business registration form either uploaded by the user or obtained by the Docufetch component of the OSP 598 from a particular public web site of various public/government web sites based on the business identifier input by the user to input field of the adaptive UI 504. Shown is selectable UI element 1708 which the user may select to edit or add to the information displayed in the directors information section 1706.
Also shown are interactive UI elements such as a back button 1710 to proceed to a previous screen or step in the process, a save and continue later button 1712 to save the user's progress in the process to continue at a later time, and a documents signing button 1714 to initiate a UI driven process for the user to sign documents based on the displayed content being verified by the user as correct.
The UI 1800 may appear or be made available by the tax registration engine 586 in response to or otherwise based on the user selecting to sign documents to progress in completion of the process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return. For example, such selection may be made by the user selecting the documents signing button 1714 in the UI 1700 of
Shown in UI 1800 is UI section 1820 which may display the business name and other relevant company information of the company providing the POA, such as the company name “Supercell Oy”, country of origin, etc. Also displayed is selectable element 1808 which the user may select in order to proceed to a seller page with further information regarding the seller. Selectable element 1810 is displayed which the user may select to proceed to a notes UI into which the user may enter notes. Selectable element 1812 is also displayed which the user may select to proceed to a documents page where the user can see and select various documents related to the process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return. UI section 1802 displays a current registration application number for which a POA is being generated and other application information.
Selectable element 1822 represents a particular POA of a possible plurality of POAs (in progress or completed) from which to select. Selectable element 1822 is selectable to display in UI 1800 the particular POA 1806 which selectable element 1822 represents and also displays a current status of the currently selected and displayed POA 1806. UI section 1804 provides various selectable document navigation and viewing options to navigate through and view displayed POA 1806, as well as to upload and download POA 1806. Displayed POA 1806 may also include an instruction page including instructions for the user for how to complete the POA using by using UI 1800. A “Review Power of Attorney” section of UI 1800 may include a business information user input section 1816 which includes input fields in one consolidated section of the UI 1800 for the user to input text for particular business information items which the user needs to fill in, which may also be highlighted for the user within displayed POA 1806. The “Review Power of Attorney” section of UI 1800 may also include a legal representatives user input section 1818 which includes input fields in one consolidated section of the UI 1800 for the user to input text to indicate the legal representative(s) to which the POA 1806 is being granted, which the user may need to fill in and may also be highlighted for the user within the displayed POA 1806. In an example embodiment, the user may select the “Complete” UI element 1814 once the required data is entered via UI 1800 for the POA in order to initiate a process of signing the POA.
If an automated process as described above fails or is determined to not exist for the above tasks, then the process may proceed instead to collect such information or collect such documentation by input or document upload via adaptive UI 504 prompting a user to do so. In cases where an electronic signature is acceptable for registration or signing documents required or associated with registration, the process may proceed to generate a signature link for such signatures and communicating such to the user. Otherwise, such documents are provided electronically to the user with instructions, such as instructions 1902, for how to sign and provide such signed documents back to OSP 598.
In particular, UI 1900 is an example UI enabling a user to download the relevant generated document for signature, having the document signed by a legal representative of the applicable company, scanning the signed document and then uploading the signed document to the OSP 598, such that the registration process may continue. In one embodiment, UI 1800 may appear as a result of the user selecting the “Complete” UI element in UI 1800 of
In an example embodiment, UI 2000 may be displayed in response to or otherwise based on the user uploading a document via UI element 1602 of UI 1600, UI element 1908 of UI 1900, or another corresponding UI element of adaptive UI 504. In the present example, the tax registration engine 586 recognized or otherwise detected the uploaded document was unclear, illegible, unreadable or did not meet a particular quality standard. In particular, in response to this detection, a “Failed” notice 2002 is displayed on UI 2000 indicating the uploaded document is not able to be clearly read. A selectable UI element 2006 is displayed for the user to select to re-upload the document, such that a clear image is obtained. The uploaded document 2004 is displayed and a selectable UI element 2008 is also displayed which the user may select to remove the document before uploading it again.
In an example embodiment, UI 2100 may be displayed, for example, displayed in response to or otherwise based on the user uploading a document via UI element 1602 of UI 1600, UI element 1908 of UI 1900, another corresponding UI element of adaptive UI 504 or re-uploading a document via UI element 2006 in UI 2000. In the present example, the tax registration engine 586 recognized or otherwise detected the uploaded document is clear, readable, such as to meet a particular quality standard. The uploaded document 2102 is displayed for visual inspection by the user. A save and close button 2104 is also displayed, which the user may select to save the current progress of the user in the process for generating a registration form for registering with a VAT tax authority or for filing a VAT tax return and to close the UI 2100.
UI 2200 may be presented to the user indicating the status of signatures needed in each different jurisdiction for which registration is being applied and whether a wet signature is required or electronic signature is available. A selectable UI element associated with each status indication on the UI 2200 may be selected by the user to perform the electronic signature or receive instructions for performing the wet signature. In an example embodiment, UI 2200 may be displayed in response to or based on the user selecting the documents signing button 1714 in UI 1700 of
In the present example, selectable UI element 2202 is displayed indicating the signatures needed for registration in Germany are complete. Selectable UI element 2208 may be selected, for example, to view and/or download such signed documents and signatures and/or perform other processes and tasks related to such signed documents and signatures.
Selectable UI element 2204 is displayed indicating one or more signatures are still needed for registration in the UK, and that such documents may be digitally signed. Selectable UI element 2210 may be selected, for example, for the user to digitally sign such documents and/or perform other processes and tasks related to such documents and signatures needed.
Selectable UI element 2206 is also displayed indicating one or more signatures are still needed for registration in France and that a wet signature is required. Selectable UI element 2212 may be selected for the user to download, edit, sign, scan and/or upload such signed documents and/or perform other processes and tasks related to such documents and signatures needed for registration in France. For example, selection of UI element 2206 may cause one or more UIs, such as UI 1400, UI 1500, UI 1700, UI 1800, UI 1900, UI 2000 and/or UI 2100 to be displayed for completion of signing documents and/or providing signatures still needed for registration in France.
In an example embodiment, UI 2300 may be displayed to and used internally by administrators of the OSP 598 for processing and tracking registrations, such as VAT registrations, as well as for configuring the WFaaS component 592 in order to control the workflows of the ARS 594 to manage the data collected, generated, and processed, and to manage the process for generating a registration form.
As shown in UI 2300, displayed is a list of internal tasks 2316 that are to be performed in order to move registrations forward. The tasks may be driven by the WFaaS component 592. Shown in the list of internal tasks 2316 are some tasks ready to be performed in order to review registration documents the system has generated for the customer to sign and for the OSP 598 to submit to the applicable tax authority system. The administrator or agent user may select a displayed task in the list of internal tasks 2316 to view more detail regarding that task, claim that task, change a status of the task, modify the task and/or modify a workflow regarding that task or corresponding registration.
Displayed above the list of internal tasks 2316 are various filters that may be applied to select registration tasks having certain characteristics related to the corresponding registration or task. In particular, displayed are user input fields or menus to filter registration tasks based on seller name 2302, external reference ID 2304, task type 2306, associated jurisdiction 2308, source 2310, action 2312 and country of origin 2314. Also displayed is a selectable UI element 2318 to apply the selected filters to view the resulting filtered tasks and a selectable UI element 2320 to clear the filter selections.
Shown is a registration processing component 2402 which performs various tasks, steps and/or operations of registration as disclosed herein and may include the computer system 595 of
The registration processing component 2402 includes a gather preliminary data component 2404 which performs various tasks, steps and/or operations of gathering and collecting data as disclosed herein (e.g., such as those of the identifier component of the OSP 598, the Docufetch component of the OSP 598 and/or the information extractor component 556 of
The assemble registration packet component 2410 performs various tasks, steps and/or operations of assembling the registration packet for particular tax jurisdictions including generating the registration form using the reviewed data received from the gather preliminary data component 2404 (e.g., such as those of the form generator of the OSP 598). The assemble registration packet component 2410 includes an organize data component 2412 that organizes data for including it on the registration form and otherwise formatting it in a customized manner for submission to a system of a particular tax jurisdiction according to that particular tax jurisdiction's system requirements. The assemble registration packet component 2410 also includes a prepare documents to submit component 2416 that prepares the applicable documents, such as the registration form and supporting documents, such as identification documents and/or POAs, for electronic submission to a system of a particular tax jurisdiction according to that particular tax jurisdiction system requirements. The assemble registration packet component 2410 also includes a resolve missing parts component 2418 which resolves (e.g., obtains) missing or incomplete data and/or forms according to the articular tax jurisdiction's system requirements, which may be detected and/or resolved at the stage of assembling the registration packet.
The system 2400 also includes a submit registration packet component 2420 that, once the registration packet has been properly assembled by the assemble registration packet component 2410, electronically submits the registration packet with the applicable tax jurisdiction system of various tax authorities 2424. The submit registration packet component 2420 may also submit the registration packet to a ready filings onboarding component 2422. The ready filings onboarding component 2422 may automatically prepare a corresponding tax return document or data according to requirements of the applicable tax jurisdiction system of the various tax authorities 2424 and then electronically communicate with the applicable tax jurisdiction to electronically file the tax return at the appropriate time with a system of applicable tax jurisdiction according to requirements of the applicable tax jurisdiction.
In various example embodiments, the operations described with respect to swimlane diagram 2500 may be performed by one or more components of the ARS 594 depicted in
At 2502, various applicable data about the customer and business has been passed to the tax registration engine 586 resulting from an online purchase (i.e., online “buy” of services of the OSP 598) and/or via other activities the customer has had with the OSP 598 and/or services provided by the OSP 598, such as a VAT checker service, OSP 598 account creation, other tax compliance services, etc. A questionnaire is thus presented via the customer UI for preparing the tax registration that has fewer questions than would have otherwise been presented if such data had not been passed to the tax registration engine 586, thereby increasing efficiency of the system.
At 2504, a document upload task for an identification document (e.g., a passport) is initiated via the customer UI, such as via adaptive UI 504. The back-end automation component (e.g., the information extractor of the OSP 598) performs an automated review of the uploaded identification document and an OCR process on the document. For example, at 2506 the automated review may include a determination of whether there is at least an 80% confidence that the document is valid and usable data is extracted from the document.
At 2508, in the internal UI (e.g., in an OSP internal adaptive UI) the customer data and documents are visible in a license console UI from the time the order or registration process is begun, even if there is no action to be taken. The administrator user or other agent of the OSP 598 may edit customer information and documents to handle escalation of registration issues in the internal UI.
At 2510 it is determined whether the document passed an automated review performed at 2506. If the document did not pass automated review (e.g., there was no real-time rejection of the document) then the document upload task remains open and the process proceeds back to 2504 for the user to re-upload the document.
In an example embodiment, the user may upload their passport or other relevant document as described herein via the UI and the back-end automation of the OSP 598 may then automatically electronically review and extract information from the passport image relevant for completing the registration process (e.g., using automated OCR processes). The customer data and documents are visible via the OSP 598 internal UI (e.g., in the OSP internal adaptive UI) during the registration process. Such customer data and documents are also editable and able to be managed via the OSP internal UI to handle escalations and otherwise facilitate the registration process. If the document passes auto-review and the questionnaire is complete, the process proceeds to 2516 shown in
At 2516, for example, an automated pull of the business' Articles of Incorporation and Trade Register from various applicable public/government web sites is performed. There may be separate such automations (which may be performed simultaneously or concurrently) for different sellers (e.g., for “X” and “Y” sellers) to thus improve speed of automated document registration and electronic document generation technology and computer networks for multiple systems of multiple sellers that are part of the network, thereby improving such technologies.
In an example embodiment, the OSP 598 automatically pulls, via the back-end automation, relevant documents from external web sites and/or data sources relevant to the registration process (e.g., Articles of Association, a Trade Register document and/or other data) using or otherwise based on identifying information and/or other information provided via the questionnaire and/or relevant uploaded documents (e.g., a passport or other identification document).
At 2518, an artificial intelligence/machine learning (AI/ML) process may also be used by OSP 598, via the back-end automation, to facilitate the registration process by detecting missing customer information and automatically completing such missing information that is useful for the registration process. For example, the AI/ML system may be trained using training data including example complete documents and data for the registration process labeled as such and/or use training data including example incomplete documents and data for the registration process labeled as such to learn to recognize complete and incomplete documents and data for the registration process. If the automation described above fails or doesn't exist, at 2530 the administrator (e.g., an agent of the OSP 598) may use the OSP 598 internal UI to perform the document upload and perform entry of the applicable data via the OSP 598 internal UI.
At 2520 the OSP 598, via the back-end automation, automatically electronically generates documents needed for signature to complete the registration process, such a powers of attorney (POA) and/or other relevant documents. An example of a UI presented to the customer/user for electronically completing the power of attorney is shown in
At 2522, in cases where an electronic signature is acceptable for registration, the back-end automation of the OSP 598 proceeds to generate a signature link for such signatures on applicable documents, communicates such to the user and provides an alarm or other alert via the customer UI if the electronic signature process fails.
Otherwise, if an electronic signature is not acceptable for registration, at 2512 such documents are provided electronically to the user via the customer UI (e.g., via adaptive UI 504) with instructions for how to download, scan, sign and provide such signed documents back to the OSP 598. For example, UI 1800 of
After such signatures are obtained either at 2522 or 2512, the OSP 598 may also, in parallel with the registration packet generation at 2536 shown in
In response to such signatures being obtained at 2512, at 2536 the OSP 598 electronically generates a final submission packet ready to print as a single file and a packet quality review is performed electronically at 2540. Also, at 2544 the percentage of packets successfully passing quality review on the first attempt may be a key performance indicator (KPI) tracked by the OSP 598.
In response to the generated packet passing packet quality review at 2540, the OSP 598 may determine at 2538 whether there are any language translations required. If so, then at 2546 the packet is automatically translated or sent for translation, such as by a translator of the OSP 598. Otherwise, the process may proceed to 2550 in
In response to the translation being completed, at 2550 shown in
After the OSP 598 receives the registration certificate (e.g., VAT Certificate) back from the applicable registration authority, at 2556 the OSP 598 then records applicable details in a tax compliance task that may be displayed in the internal UI. Such details may include tax amounts due and/or other details regarding electronic filing a tax return or other compliance requirements. At 2558 The OSP 598 then performs a confirm filings task, or opens such a task for display in the internal UI as needing to be completed, to confirm and record various registration data and tasks have completed correctly. The OSP 598 may also transmit or surface various applicable notices regarding the completion of the registration and applicable certificate to the agent of the OSP 598 via the internal UI and/or to the customer/user via the customer UI or via other electronic communications.
At 2602, the OSP 598 electronically initiates a process to collect data via a graphical user interface (GUI) to facilitate automated preparation of an electronic registration before initiating a process to remit resources from a first entity to one or more domains based on relationship instances between the first entity and a plurality of secondary entities.
At 2604, the OSP 598 electronically obtains a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify the first entity.
At 2606, the OSP 598, using at least the entity identifier, performs automated actions to electronically collect one or more support content regarding the first entity to facilitate automated preparation of the electronic registration document.
At 2608, the OSP 598 electronically generates the electronic registration based on the one or more support content.
At 2610, the OSP 598 electronically receives interchange data associated with the relationship instances.
At 2612, the OSP 598 automatically generates an electronic data sheet for the first entity based on the electronic registration and the interchange data. The electronic data sheet indicates a finalized amount of resources to be transmitted to a domain based on the interchange data.
At 2614, the OSP 598 electronically files the generated electronic data sheet with a system of the domain automatically such that further contacting the first entity for electronically filing the generated electronic data sheet is avoided beyond a previous initial setup.
At 2616, the OSP 598 electronically issues an alert to electronically request additional resources from the first entity in response to resource amounts to be transmitted to the domain based on the finalized amount of resources indicated by the generated electronic data sheet having exceeded an amount of resources received from the first entity.
At 2618, the OSP 598 automatically transmits the finalized amount of resources to the domain.
At 2702, the OSP 598 electronically establishes the pre-existing entity identifier to be associated with the first entity.
At 2704, the OSP 598 electronically identifies data from the one or more support content relevant to the electronic registration.
At 2706, the OSP 598 electronically extracts the identified data from the one or more support content in response to the electronically identifying the data.
At 2707, the OSP 598 electronically verifies the extracted data, in which the automatically generating the electronic registration is based on the extracted data.
At 2802, the OSP 598 electronically configures parameters in accordance with the initial setup by the first entity.
At 2804, the OSP 598 electronically receives, over a computer network and from multiple different remote systems, electronic records recording interchanges. The interchange data is based on at least some of the electronic records recording interchanges.
At 2806, the OSP 598 electronically extracts data concurrently from the electronic records, the data specifying the interchanges.
At 2808, the OSP 598 electronically routes the extracted data through a workflow control platform.
At 2810, the OSP 598 electronically validates the extracted data as accurate at a first location controlled by the workflow control platform.
At 2812, the OSP 598, based on the validated data, electronically executes determinations concurrently for generating electronic data sheets, including the electronic data sheet, associated with resources to be electronically filed with one or more domains.
At 2814, the OSP 598 electronically generates the electronic data sheets associated with the resources concurrently at least in part by automatically populating into electronic data sheets values resulting from the determinations.
At 2902, the OSP 598 maintains a record of past electronic activities by the first entity.
At 2904, the OSP 598 electronically determines an estimated amount of resources to be transmitted to the domain based on an analysis of the interchange data.
At 2906, the OSP 598 electronically adjusts an electronic value for the first entity according to a remittance risk determination that is based on the interchange data and the record of past electronic activities. The adjusted electronic value indicates a maximum amount of resources for which an online software platform will transmit and receive protocols to enable providing by the online software platform the maximum amount of resources on behalf of the first entity. The OSP 598 may then electronically file the generated electronic data sheets with the one or more domains automatically.
At 3002, the OSP 598 scales up an ability of the online software platform to electronically generate additional electronic data sheets for additional entities concurrently, simultaneously, or otherwise in parallel. In an example embodiment, this may be performed by enabling a first selection of components of the one or more components of the online software platform to be multiplied in order to operate concurrent, simultaneous, or otherwise parallel courses for performing additional activities to electronically generate the additional electronic data sheets concurrently, simultaneously, or otherwise in parallel. The one or more components may include one or more of: an extractor, a data router, a validator, a calculator, a form generator, and a form filer.
At 3004, the OSP 598 multiplies the first selection of components of one or more components to electronically generate additional electronic data sheets for additional entities concurrently, simultaneously, or otherwise in parallel.
At 3102, the OSP 598 scales up an ability of the online software platform to electronically file additional electronic data sheets for additional entities concurrently, simultaneously, or otherwise in parallel. In an example embodiment, this may be performed by enabling a second selection of components of the one or more components of the online software platform to be multiplied in order to operate concurrent, simultaneous, or otherwise parallel courses for performing additional activities to electronically file additional electronic data sheets concurrently, simultaneously, or otherwise in parallel. The one or more components may include one or more of: an extractor, a data router, a validator, a calculator, a form generator, and a form filer.
At 3004, the OSP 598 multiplies the second selection of components of one or more components to electronically file additional electronic data sheets for additional entities concurrently, simultaneously, or otherwise in parallel.
The embodiments described above may also use synchronous or asynchronous client-server computing techniques, including software-as-a-service (SaaS) techniques. However, the various components may be implemented using more monolithic programming techniques as well, for example, as an executable running on a single CPU computer system, or alternatively decomposed using a variety of structuring techniques known in the art, including but not limited to, multiprogramming, multithreading, client-server, or peer-to-peer, a microservice architecture, running on one or more computer systems each having one or more CPUs. Some embodiments may execute concurrently and asynchronously, and communicate using message passing techniques. Equivalent synchronous embodiments are also supported. Also, other functions could be implemented and/or performed by each component/module, and in different orders, and by different components/modules, yet still achieve the functions of the systems and methods described herein.
In addition, programming interfaces to the data stored as part of the system programs 131 and other system components described herein may be available by mechanisms such as through C, C++, C#, Python and Java APIs; libraries for accessing files, databases, or other data repositories; through scripting languages such as JavaScript and VB Script; or through Web servers, FTP servers, or other types of servers providing access to stored data. The databases described herein and other system components may be implemented by using one or more database systems, file systems, or any other technique for storing such information, or any combination of the above, including implementations using distributed computing techniques.
Different configurations and locations of programs and data are contemplated for use with techniques described herein. A variety of distributed computing techniques are appropriate for implementing the components of the embodiments in a distributed manner including but not limited to TCP/IP sockets, RPC, RMI, HTTP, RESTful (REST) APIs, Web Services (XML-RPC, JAX-RPC, SOAP, and the like). Other variations are possible. Also, other functionality may be provided by each component/module, or existing functionality could be distributed amongst the components/modules in different ways, yet still achieve the functions described herein.
Where a phrase similar to “at least one of A, B, or C,” “at least one of A, B, and C,” “one or more A, B, or C,” or “one or more of A, B, and C” is used, it is intended that the phrase be interpreted to mean that A alone may be present in an embodiment, B alone may be present in an embodiment, C alone may be present in an embodiment, or that any combination of the elements A, B and C may be present in a single embodiment; for example, A and B, A and C, B and C, or A and B and C.
As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present disclosure. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within a scope of embodiments of the present disclosure as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
The various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the embodiments in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the disclosure.
Claims
1. A method, including:
- electronically initiating a process to collect data via a graphical user interface (GUI) to facilitate automated preparation of an electronic registration before initiating a process to remit resources from a first entity to one or more domains based on relationship instances between the first entity and a plurality of secondary entities;
- electronically obtaining a pre-existing entity identifier that had been previously used by an electronic system of at least one authority entity to identify the first entity;
- using at least the entity identifier, performing automated actions to electronically collect one or more support content regarding the first entity to facilitate automated preparation of the electronic registration document;
- electronically generating the electronic registration based on the one or more support content;
- electronically receiving interchange data associated with the relationship instances;
- automatically generating an electronic data sheet for the first entity based on the electronic registration and the interchange data, the electronic data sheet indicating a finalized amount of resources to be transmitted to a domain based on the interchange data;
- electronically filing the generated electronic data sheet with a system of the domain automatically such that further contacting the first entity for electronically filing the generated electronic data sheet is avoided beyond a previous initial setup;
- electronically issuing an alert to electronically request additional resources from the first entity in response to resource amounts to be transmitted to the domain based on the finalized amount of resources indicated by the generated electronic data sheet having exceeded an amount of resources received from the first entity; and
- automatically transmitting the finalized amount of resources to the domain.
2. The method of claim 1, in which the automatically generating the electronic registration includes:
- electronically establishing the pre-existing entity identifier to be associated with the first entity;
- electronically identifying data from the one or more support content relevant to the electronic registration;
- electronically extracting the identified data from the one or more support content in response to the electronically identifying the data; and
- electronically verifying the extracted data, in which the automatically generating the electronic registration is based on the extracted data.
3. The method of claim 2, in which the automatically generating an electronic data sheet includes:
- electronically configuring parameters in accordance with the initial setup by the first entity;
- electronically receiving, over a computer network and from multiple different remote systems, electronic records recording interchanges, in which the interchange data is based on at least some of the electronic records recording interchanges;
- electronically extracting data concurrently from the electronic records, the data specifying the interchanges;
- electronically routing the extracted data through a workflow control platform;
- electronically validating the extracted data as accurate at a first location controlled by the workflow control platform;
- based on the validated data, electronically executing determinations concurrently for generating electronic data sheets, including the electronic data sheet, associated with resources to be electronically filed with one or more domains;
- electronically generating the electronic data sheets associated with the resources concurrently at least in part by automatically populating into electronic data sheets values resulting from the determinations.
4. The method of claim 3, further comprising:
- maintaining a record of past electronic activities by the first entity;
- electronically determining an estimated amount of resources to be transmitted to the domain based on an analysis of the interchange data; and
- electronically adjusting an electronic value for the first entity according to a remittance risk determination that is based on the interchange data and the record of past electronic activities, the adjusted electronic value indicating a maximum amount of resources for which an online software platform will transmit and receive protocols to enable providing by the online software platform the maximum amount of resources on behalf of the first entity.
5. The method of claim 4, further comprising:
- electronically filing the generated electronic data sheets with the one or more domains automatically.
6. The method of claim 5 in which the electronically generating the electronic data sheets is performed by the online software platform, and further comprising:
- scaling up an ability of the online software platform to electronically generate additional electronic data sheets for additional entities in parallel by enabling a first selection of components of the one or more components of the online software platform to be multiplied in order to operate parallel courses for performing additional activities to electronically generate the additional electronic data sheets in parallel, in which the one or more components include one or more of: an extractor, a data router, a validator, a calculator, a form generator, and a form filer.
7. The method of claim 6, further comprising:
- multiplying the first selection of components of one or more components to electronically generate additional electronic data sheets for additional entities in parallel.
8. The method of claim 7 in which the electronically filing the generated electronic data sheets is performed by the online software platform, and further comprising:
- scaling up an ability of the online software platform to electronically file additional electronic data sheets for additional entities in parallel by enabling a second selection of components of one or more components of the online software platform to be multiplied in order to operate parallel courses for performing additional activities to electronically file the additional number of electronic data sheets in parallel.
9. The method of claim 8, further comprising:
- multiplying the second selection of components of one or more components to scale up the ability of the online software platform to electronically file additional electronic data sheets for additional entities in parallel.
10-27. (canceled)
Type: Application
Filed: Jun 7, 2023
Publication Date: Dec 14, 2023
Inventors: John Tindell (Brighton), Tobin Mathew (Epsom), Will Colborn (Brighton), Albert Kumar Boulus (Cary, NC), Anup David Parekh (Brighton), Masa Karahashi (San Mateo, CA), Emmanuel Thangaraj (Morgan Hill, CA), Narasimha Paila (Mountain House, CA), Alex Huang (Cupertino, CA), Anh Carter (Brighton), Swapnil Singh (Hove), Patricia Oakley (Hove), Matt Buckley (Hove), Graham Edwards (Pevensey & Westham), Scott Seely (Galesville, WI), Matt Johnson (Raleigh, NC)
Application Number: 18/207,091
