Patent Application
20230055115
Each year in the United States, roughly 40 million Schedules K1 are distributed from about 7.5 M million flow-through entities. Flow-through entities include Partnerships, S Corporations and Trusts. A Schedule K1 comprises a 1-page IRS form, which is often called a “face page,” and frequently more than 50 pages of free-form, whitepaper statements that describe the federal, state and international income tax filing requirements of a partner.
Pursuant to Section 6031(b), partnerships are required to furnish to its partners information as is necessary to enable each partner to compute its distributive share of partnership income or loss from such trade or business. But because there is no standardization of Schedule K1 packets, each of the 7.5 M schedule K-1 packets is unique. There is no standard schema that can be followed to provide all federal, state and international data to a partner and there is no standard data request (from the partnership) where a partner invested in multiple (sometimes hundreds) can respond once and have that data transmitted to all appropriate partnership entities. Current processing for these types of documents involves a human reviewing the Schedule K1 packet, typically in PDF form, and hand-typing information into their processing software.
There have been a number of OCR scanning technologies introduced that have tried to tackle this problem but they do not work. The submitter of this patent application also has a pending patent application, U.S. Pre-Grant Publication No. 2021/0082062 filed Sep. 16, 2019 for a “Machine Learning System for Summarizing Tax Documents with Non-Structured Portion,” which is hereby incorporated by reference. AI-powered machine-learning solutions have made great strides towards extracting much of the data provided in a Schedule K-1, but it is not exact and it is often not everything a specific partner needs to meet its filing requirements.
The problem is further exacerbated as a result of the tiered partnership structure. Many schedule K-1 packets received are not just the reporting of a single partnership's activity, but rather a culmination of activities that are aggregated and distributed to various tiers of owners. The result is often a Schedule K-1 packet that may provide the same data element reported multiple times vs. the aggregate reporting for all tiers within one summary.
Therefore, there is a need for a system that overcomes one or more of these issues.
According to one aspect, this disclosure is a digital tax data exchange system. The system includes a schema validation subsystem to validate one or more structured data files are formatted in accordance with a universal data schema based on entity-specific data requirements. The plurality of structured data files relate to K-1 producers, which are financial entities that issue schedule K-1 documents and K-1 receivers, which are persons to whom schedule K-1 documents are issued. In response to validating the one or more structured data files, the schema validation subsystem is to generate a validation certificate that is associated with the one or more structured data files. The system includes a registration manager, on one or more processors, to register a plurality of legal entities as a K-1 producer and/or a K-1 receiver as registered users in a database. The registration manager is to perform a digital identity validation process. The system also includes a connections subsystem, on one or more processors, to make connections between one or more K-1 producers and one or more K-1 receivers to establish access control therebetween. The access control between connected K-1 producers and K-1 receivers provides data access to one or more of each other's structured data files.
According to another aspect, this disclosure is a computerized method for digital tax data exchange. The method includes validating one or more structured data files are formatted in accordance with a universal data schema based on entity-specific data requirements. The plurality of structured data files relate to K-1 producers, which are financial entities that issue schedule K-1 documents and K-1 receivers, which are persons to whom schedule K-1 documents are issued. In response to validating the one or more structured data files, the method includes validating includes generating a validation certificate that is associated with the one or more structured data files. The method includes registering a plurality of legal entities as a K-1 producer and/or a K-1 receiver as registered users in a database, wherein the registering step includes a digital identity validation process. The method also includes making connections between one or more K-1 producers and one or more K-1 receivers to establish access control therebetween. The access control between connected K-1 producers and K-1 receivers provides data access to one or more of each other's structured data files.
According to a further aspect, this disclosure is one or more non-transitory, computer-readable storage media comprising a plurality of instructions stored thereon that, in response to being executed, cause a computing device to validate one or more structured data files are formatted in accordance with a universal data schema based on entity-specific data requirements. The plurality of structured data files relate to K-1 producers, which are financial entities that issue schedule K-1 documents and K-1 receivers, which are persons to whom schedule K-1 documents are issued. In response to validating the one or more structured data files, the instructions generates a validation certificate that is associated with the one or more structured data files. There are instructions to register a plurality of legal entities as a K-1 producer and/or a K-1 receiver as registered users in a database, which includes a digital identity validation process. There are also includes to make connections between one or more K-1 producers and one or more K-1 receivers to establish access control therebetween. The access control between connected K-1 producers and K-1 receivers provides data access to one or more of each other's structured data files.
The concepts described herein are illustrated by way of example and not by way of limitation in the accompanying figures. For simplicity and clarity of illustration, elements illustrated in the figures are not necessarily drawn to scale. Where considered appropriate, reference labels have been repeated among the figures to indicate corresponding or analogous elements.
While the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described herein in detail. It should be understood, however, that there is no intent to limit the concepts of the present disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.
References in the specification to “one embodiment,” “an embodiment,” “an illustrative embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. Additionally, it should be appreciated that items included in a list in the form of “at least one A, B, and C” can mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C). Similarly, items listed in the form of “at least one of A, B, or C” can mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).
The disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on a transitory or non-transitory machine-readable (e.g., computer-readable) storage medium, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).
In the drawings, some structural or method features may be shown in specific arrangements and/or orderings. However, it should be appreciated that such specific arrangements and/or orderings may not be required. Rather, in some embodiments, such features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of a structural or method feature in a particular figure is not meant to imply that such feature is required in all embodiments and, in some embodiments, may not be included or may be combined with other features.
In some embodiments, this disclosure provides a system including a universal schema for the thousands of data points needed to provide federal, state and international information. The system includes logic built into the schema where it determines the specific information needed for each of the different legal entities that would receive a Schedule K-1 and their respective data needs. These legal entities include:
Combining the universal schema with entity-specific logic will significantly streamline the process but the facilitation of the data transmission is the last piece of the puzzle. In some embodiments, the system allows the seamless, digital transmission of data between these two worlds, and that seamless digital transmission of data will be facilitated by a K-1 Exchange. For example, K-1 receivers could post out to the K-1 Exchange all of their demographic information, and that data could then be automatically pulled into the world of the K-1 producers, who would then use it to create K-1s that have the correct demographic information on them. Additionally, K-1 receivers can provide their composite and withholding eligibility information so that the K-1 producers automatically receive it and have all of the information that they need to properly handle state and local taxes.
Once the K-1 producers have all the information that they need to do their work, they can then complete their K-1s and provide all of the necessary federal, state, international, capital, and basis details seamlessly and digitally to the K-1 receivers. This enables having all of that data automatically show up in the correct spot with no human data entry necessary for the K-1 receivers.
Referring now to
The server 102 and/or computing devices 104 may be embodied as any type of computation or computer device capable of performing the functions described herein, including, without limitation, a computer, a server, a workstation, a desktop computer, a laptop computer, a notebook computer, a tablet computer, a mobile computing device, a wearable computing device, a network appliance, a web appliance, a distributed computing system, a processor-based system, and/or a consumer electronic device. Depending on the circumstances, the server 102 and computing devices 104 could include a processor, an input/output subsystem, a memory, a data storage device, and/or other components and devices commonly found in a server or similar computing device. Of course, the server 102 may include other or additional components, such as those commonly found in a server computer (e.g., various input/output devices), in other embodiments. Additionally, in some embodiments, one or more of the illustrative components may be incorporated in, or otherwise form a portion of, another component. For example, the memory, or portions thereof, may be incorporated in the processor in some embodiments. The server 102 and computing devices 104 may include a communication subsystem, which may be embodied as any communication circuit, device, or collection thereof, capable of enabling communications between the server 102 and computing devices 104 over the network 106. For example, the communication subsystem may be embodied as or otherwise include a network interface controller (NIC) or other network controller for sending and/or receiving network data with remote devices. The NIC may be embodied as any network interface card, network adapter, host fabric interface, network coprocessor, or other component that connects the server 102 and computing devices 104 to the network 106. The communication subsystem may be configured to use any one or more communication technology (e.g., wired or wireless communications) and associated protocols (e.g., Ethernet, InfiniBand®, Bluetooth®, Wi-Fi®, WiMAX, 3G, 4G LTE, etc.) to effect such communication.
In an illustrative embodiment, the server 102 establishes an environment during operation to provide one or more features of a K-1 Exchange 108. In the example shown, the K-1 Exchange 108 includes a collection of .K-1X documents 110, a registration manager 112, a connections subsystem 114, a universal information request 116, a publishing engine 118, and an API gateway 120. As shown, the various components of the environment K-1 Exchange 108 may be embodied as hardware, firmware, software, or a combination thereof. As such, in some embodiments, one or more of the components of the K-1 Exchange may be embodied as circuitry or collection of electrical devices (e.g., registration manager circuitry 112, connections subsystem circuitry 114, universal information request circuitry 116, publishing engine circuitry 118, and API gateway circuitry 120). It should be appreciated that, in such embodiments, one or more of the registration manager circuitry 112, connections subsystem circuitry 114, universal information request circuitry 116, publishing engine circuitry 118, and API gateway circuitry 120 may form a portion of the processor, the NIC, the I/O subsystem, and/or other components of the server 102 and/or computing devices 104. Additionally, in some embodiments, one or more of the illustrative components may form a portion of another component and/or one or more of the illustrative components may be independent of one another.
Digital K-1 (.K-1X File)
As discussed herein, the K-1 Exchange 108 is configured to generate, at least in part, a plurality of structured data files representing K-1 data, which are represented by .K1X documents 110. The .K1X documents 110 are formatted according to a defined schema, which will be referred to as the K-1 schema. The .K1X documents provides a digital, standardized specification for the K-1 statement.
To understand the digital exchange of data between K-1 Producers and K-1 Recipients, one must first understand the concept of getting to the standardized specification of the .K1X documents. Consider a PDF file, there are many tools out in the market that can create/edit/transmit/read these files. Through much iteration, planning, etc., PDF files have become a widely adopted standard with universal specifications that must be adhered to in order to consume and process the .pdf file extension and use in resulting solutions. As explained herein, there is not a mechanism to provide the exact and holistic K-1 information to a receiving entity without some element of human interpretation or automation through a machine learning model that is still doing a similar interpretation as the human but in a much more scaled, sophisticated fashion, all still susceptible to incomplete/inaccurate information. Thus, the file format of .K1X documents 110, or also referred herein as the “Digital K-1,” is the answer to provide the standardization for K-1s.
Referring now to
In some embodiments, the K-1 data 406 portion of the .K1X document 110 is in .XML or .JSON file format; however, other formats could be used depending on the circumstances. The K-1 data 406 is the core component of the .K-1X document 110, which contains the necessary, structured information for the recipient for their K-1 reporting. In some embodiments, the K-1 data 406 includes one or more of the following:
Issuance Type 508—Throughout the year a producer of a K-1 may report multiple times K-1 data to assist their receivers in their own tax planning activities. The issuance types for most K-1s is either an estimate, draft, or final. It is important for a producer to specify this as it will drive downstream decision making and logic for a receiver when they consume the data.
The data file 402 can also contain K-1 data relevant to Federal 510, State & Local 512, and International (Foreign) 514 reporting requirements. It is not required to provide all three of the components 510, 512, 514 in one file, due to the fluid nature of K-1 reporting throughout a compliance season, there could be multiple digital K-1 files distributed to a receiver. For example, the producing entity may deliver Federal K-1 data 510 only early on in the process, then once state information 512 is finalized they can build a separate .K1x document 110 containing only the new state information 512. In some cases, there may be one or more attachments 516 in the data file 402.
Referring again to
The creation of the K-1 exchange certificate 408 and how the certificate 408 is added to the .K1X document 110 is explained herein. An example K-1 exchange certificate 408 is shown in
The .K1X document 110 may include K-1 attachments 404, which is an optional component of the Digital K-1 that may provide additional information that is outside the core K-1 Data file 406 that is supporting information in regards to the K-1 schema. An example of this might be the actual PDF(s) of the K-1s that were filed with the taxing jurisdictions to ensure the recipient as both their digital and pdf/electronic copy of their K-1s. The key for these attachments is to ensure they are communicated in the K-1 Data file, so there is some element of a lookup or “Table of contents” of what is provided in the subsequent attachments folder, it will help solutions downstream understand what they are consuming so they can route the information appropriately.
K-1 Schema
At its highest level the K-1 schema, is a composition of data structures, types, and fields that follow a defined set of rules to follow when constructing a resulting file containing data relative to a K-1. In some embodiments, the schema is managed by a collection of .XSD (XML Schema definition) documents that specifies how to formally describe the elements of the K-1 in either a resulting .JSON file or as mentioned previously in the Digital K-1 file section, an .XML file (e.g. —K1Data.xml). The contents of these .xsds is an embodiment of more than 10,000+ fields that spans all required federal, state & local, and international tax data for three different flow-through entity types (Partnerships—1065, S-Corporations—1120S, and Trusts—1041). Typically, the schema definition is an annual activity, and it is assumed adjustments are made for future tax year support (including the potential for new jurisdictions).
In some embodiments, the K-1 schema is designed in what is called a “Venetian Blind Pattern”, which means the resulting xml data based off the schema contains only one global element. All the other elements are local. Element declarations are nested within a single global declaration by means of named complex types and element groups. Those types and groups can be reused throughout the schema and must define only the root element within the global namespace. This design is used for a couple purposes, it ensures one root attribute when the K-1data is submitted to inspect the contents of the file and it allows for re-use common schema types for similar data structures across the supported jurisdictions.
In some embodiments, all elements and types of the schema are defined under the “K1X” namespace which is a logical grouping container for a defined types and elements. In the example shown in
In some embodiments, the K-1 schema includes versioning, which is an important aspect to any structured data created that must adhere to a specified schema. It is important to be able to create different versions of XML Schemas. In some applications, schemas need to change over time to meet new requirements that may emerge, as is the case with K-1s because new regulation and reporting requirements across all of these taxing jurisdictions are subject to change. It is often not practical to simultaneously replace all the deployments of the old schemas with the new ones. Thus, the K-1 schema and subsequently the .K1X documents 110 and K-1 Exchange 108 is designed in a manner to support different versions coexisting in the system. For example, an initial version of the K-1 Schema is defined and released for general availability, then a new law/regulation could be in put place in a particular jurisdiction in the middle of a time period before a new major version is released, the K-1 schema is updated with a minor version to support the additional data point, but then there is still support for the prior minor version in case producers or receivers of digital k-1s had plans/operations set forth expecting the prior version and the newly introduced minor version does not apply to them anyway.
Below is a high-level outline of how the versioning of the K-1 schema could be managed, note much like the explanation of the structure previously mentioned this mechanics/concepts of this applies to both XSD/XML and JSON schema medium formats in order to provide flexibility for the developing entity to best align their capabilities in those particular languages.
K-1 Exchange
User and Legal Entity Registration and Verification
The registration manager 112 is configured to register users with the K-1 Exchange 108.
After the user provides the attributes to setup their profile, they are sent a verification link to the provided email address, the link contains a temporary/unique hash sent to only that email address. The user logs into their provided email account and clicks the unique link back to the K-1 Exchange 108 to conclude the validation of a legitimate email address provided by the user (block 1802).
To complete the user registration feature, users may be required to setup two factor authentication (block 1804) via a K-1 Exchange identity management service. The K-1 Exchange 108 may run through the following example steps to setup two factor authentication and additional security items.
After setting up the additional security items and two factor authentication, the user's account registration is complete, they would move onto the legal account registration feature (block 1806) to either register new legal entities on the K-1 Exchange 108 of which they will administer, or request association to existing legal entities on the K-1 exchange 108 so they can be added as a contact to help administer activities for that legal entity.
In order to interact either as a producer or receiver of K-1s a legal entity must go through a valid registration process to ensure its identification and unique account so when exchanging information the party on the other side can be guaranteed they are communicating with whom they expect. Registration is uniquely defined at the Legal Entity level, this is because a K-1 is the tax reporting document between two parties (Part A, the producer, and Part B, the receiver), which these entities are registered as unique taxpayers with the IRS. As illustrated in
There may then be a verification check (block 1904). For example, for each legal entity registering on the exchange, digital identity verification may be provided. The verification requirements may be slightly different for individuals and non-individuals. For example, for non-individuals, a combination of the following options in conjunction of the required legal entity information mentioned above may be provided to ensure identity: official website (or affiliated website), email domain for valid users with administration rights to the legal entity account, documentation (examples would be letters of incorporation or partnership agreements), etc. For individuals, a combination of the following options in conjunction of the required legal entity information mentioned above may be provided to ensure identity: ID verification (official government issued identification) and completion of identity history questionnaire. Since the verification of an individual is a little bit more meticulous to track down as opposed to a legal entity, services from providers specializing in digital identity verification may be leveraged. In some cases, the identity history questionnaire may include one or more of the following: build the request for identity history, send the request to the expected ID service, processing an XML Response for a list of questions for the end user to validate their identity, Submitting the answers to the questions, and process an XML response with a pass/fail result for each answer submitted.
Next, the contact information for the responsible part(ies) is provided (block 1906). For individual legal entity accounts, there could be requirements in which primary user account (email) must be identified and this contact must have completed in the user registration. If additional user accounts end up being associated to the legal entity account, there could be requirements for at least 1 primary user account established to ensure a governing approval/verification of the additional users. For non-individual legal entity accounts, primary user account (email) must be identified and this contact must have completed the user registration. In some cases, the primary email address for the primary contact must have the email domain that represents the legal entity (e.g., Crowe LLP would be @crowe.com). If additional user accounts end up being associated to the legal entity account, there must be at least 1 primary user account established to ensure a governing approval/verification of the additional users.
Connection Discovery Between Producing and Receiving Legal Entities
Once users and legal entities have been registered and verified on the system, the connection subsystem 114 is configured to facilitate connecting all of these legal entities together in a secure manner via a producer-receiver relationship that is mutually agreed upon between the two parties. Establishing this relationship can be initiated via either side, depending on which side initiates the discovery or “request to connect” the receiver of this request would then be responsible to accept/verify this.
Producers “Discover” their Receivers on the K-1 Exchange 108 and receivers verify/accept the connection. A legal entity that intends to produce and publish K-1s to their recipient group can request to connect/follow their recipients if those recipients have already registered on the K-1 exchange. Each producing entity maintains a list of their recipients as they need to file that with their parent federal return with the IRS (1065—Partners, 1120-S—Shareholders, and 1041—Trustees). Producers discover the recipients with the same unique information that the recipients registered with, such as:
Once the recipient is found the K-1 Exchange legal entity database, a connection request is sent from the producer with the intent “follow” for information requests received from the recipient and intent to “transmit” in order to digitally transmit K-1 information. The recipient receives this request in their K-1 Exchange connection inbox and accepts the connection. The previous steps are completed for each recipient the producer has an agreement with to communicate a K-1 to, if a connection has not already been requested and accepted from the recipient themselves.
Receivers “Discover” their Producers on the Exchange 108 and producers verify/accept the connection. A legal entity that intends to receive K-1s from a portfolio of producers can request to connect with these producers if they have already registered on the K-1 exchange. Receivers discover the producers with the same unique information that the producers registered with, such as:
Once the producer is found within the K-1 Exchange legal entity database, a connection request is sent from the receiver with the intent to “provide” information requests needed to be collected by the producing entity and subsequently intent to “receive” in order to digitally accept their K-1 information from the producing entity. The producer receives this request in their K-1 Exchange connection inbox and accepts the connection. The previous steps are completed for each producer the recipient has an agreement with to receive a K-1 from, if a connection has not already been requested and accepted from the producer themselves.
Recipient Information Reporting (Demographic, Composite, Withholding)
To understand the next feature of Recipient information reporting, it is first important to note the background context of why this feature is needed. In order for producers to accurately report the K-1 information for each recipient an information request is typically conducted of their recipients. On the flip side, recipients on the K-1 exchange will have multiple producers they are working with they are fulfilling this information request to and repeat it for each connection, often seeing a duplication of requested information. The K-1 exchange 108 is designed for each recipient to provide their annual information request only once and each producer they have an established connection with can subscribe to pull that information down into their respective preparing tax workpapers. This information request is an annual activity; it is assumed adjustments made for future tax year support (including the potential for new jurisdictions), may be incorporated into the information request depending on the circumstances.
In some embodiment, the recipient information request could include one or more of the following components:
Digital K-1 Publishing to the Exchange by Producers
As producers of K-1s, the key feature for them in the K-1 Exchange is the ability to publish their generated and/or construct their Digital K-1 files so they are transmitted for each recipient for whom they are obligated to report. The following outlines how the K-1 Exchange 108 facilitates this publishing. The K-1 Exchange 108 user securely connects/authenticate, and navigates to the specific Account/Legal-Entity combination for the K-1s they wish to publish. In some embodiments, if the option to publish digital K-1(s) information to the Exchange 108 is chosen, the user must specify if they already have a digital K-1 constructed, or need the assistance of the K-1 exchange to package up the component. If they require the K-1 exchange to construct the digital K-1, they complete the following steps: (i) specify issuance type (Estimate, Draft, Final), (ii) upload their K-1 Data (.XML or .JSON) file(s) adhering to the K-1 schema for each K-1 receiver they intend to publish, (iii) upload any additional PDF attachments (i.e. the physical K-1 files) for each K-1 receiver they intend to publish. In some cases, it is possible the producer does not yet have the ability to create a K-1 Data file and only has PDFs of K-1s. In this event, they can still use the K-1 Exchange 108 for distribution, but their K-1 PDFs will be sent to the K-1 Reader for extraction, the results are then parsed to a usable K-1 Data format to its best abilities. Once the Digital K-1s are uploaded and constructed, the next step will be to validate their contents. For each Digital K-1 that passes the required validation, the K-1 Exchange 108 will generate a K-1 Exchange Certificate file in either XML or JSON to match the K-1 Data file format. Having this file will give the downstream receiver the guarantee their Digital K-1 has gone through the proper quality checks for safe consumption. After the producer completes the publishing portion for the Digital K-1s, the K-1 Exchange 108 manages any and all notifications to inform the receivers on the K-1 Exchange 108 their digital K-1s are available to the specified receiver group the producer is connected to.
Digital K-1 Transmission from the Exchange for Receivers
As receivers of K-1s, the ability to receive their Digital K-1s so it can be consumed into their respective tax workpapers or application of choice. In some embodiments, the K-1 Exchange 108 facilitates receiving the Digital K-1 with one or more of the following steps: (i) the K-1 Exchange user securely connects/authenticates, and navigates to the specific account/legal-entity combination for the K-1s they wish to retrieve; (ii) once they have landed on the desired legal entity's dashboard, they will be able to view which K-1s they are expecting from connected producers, of those connections the ones that have gone through the functionality to publish K-1s will have a notification they are “ready” for the receiver to consume the Digital K-1; (iii) depending on the destination of the Digital K-1 there will multiple options for the receiver to choose from, such as downloading a PDF of K-1 and any other attachments (if provided), downloading the entire Digital K-1 (.K-1X file), and/or if the receiver is a user of a downstream tool, they may transfer directly into a downstream tool.
API Connectivity via general API Gateway & Developer SDK
In some embodiments, one or more functions of the K-1 Exchange 108 is exposed through APIs 120 (Application Programming Interfaces) through a controlled gateway.
In some embodiments, K-1 Exchange API resources require a valid access token for authentication. For example, there could be two ways to obtain access tokens: (i) Account Access Tokens; and/or (ii) OAuth Applications. Once an access token is obtained, the token could use HTTP Bearer Authentication, as defined in RFC6750 by the Internet Engineering Task Force (IETF), to authenticate when sending requests to the K-1 Exchange API 120. In some embodiments, there could be two methods supported to send the access token along in an API request: (i) authorization request header; and/or (ii) URI query parameter.
After an access token is obtained, one or more of the following API endpoints could be available in the K-1 Exchange 108 for programmatic interaction as opposed to interacting via direct, end-user, browser-based experiences. In some cases, not all K-1 Exchange 108 functionality will be available through the API gateway 120; for example, the recipient information reporting, could be made accessible through the API, but key functionality as it pertains to accounts, entities registered for the exchange, their connections with other entities, and K-1 package could be transmitted via the exchange 108. The endpoints shown in
In some cases, there may be a K-1 Package Certification lookup underlying API calls tied to the packages, such as for endpoint access to an integration application; for example, package certification may be passed to tax tools inside the .K-1X file from the K-1 Certification .XML or .JSON file to ensure the authenticity and validate of the Digital K-1 about to be processed.
Illustrative examples of the technologies disclosed herein are provided below. An embodiment of the technologies may include any one or more, and any combination of, the examples described below.
Example 1 is a digital tax data exchange system. The system includes a schema validation subsystem to validate one or more structured data files are formatted in accordance with a universal data schema based on entity-specific data requirements. The plurality of structured data files relate to K-1 producers, which are financial entities that issue schedule K-1 documents and K-1 receivers, which are persons to whom schedule K-1 documents are issued. In response to validating the one or more structured data files, the schema validation subsystem is to generate a validation certificate that is associated with the one or more structured data files. The system includes a registration manager, on one or more processors, to register a plurality of legal entities as a K-1 producer and/or a K-1 receiver as registered users in a database. The registration manager is to perform a digital identity validation process. The system also includes a connections subsystem, on one or more processors, to make connections between one or more K-1 producers and one or more K-1 receivers to establish access control therebetween. The access control between connected K-1 producers and K-1 receivers provides data access to one or more of each other's structured data files.
Example 2 includes the subject matter of Example 1, wherein the schema validation subsystem is to reject a data file inconsistent with the universal data schema.
Example 3 includes the subject matter of Examples 1-2, wherein the universal data schema requires structured data files with at least: (i) K-1 data; and (ii) a K-1 exchange certificate.
Example 4 includes the subject matter of Examples 1-3, wherein the (i) K-1 data; and (ii) an K-1 exchange certificate are bundled into a single data file.
Example 5 includes the subject matter of Examples 1-4, wherein the universal data schema further requires one or more attachment files.
Example 6 includes the subject matter of Examples 1-5, wherein the universal data schema requires structured data files with K-1 data including at least: (i) a producer identification; (ii) a recipient identification; (iii) a tax year; (iv) a form type; and/or (v) an issuance type.
Example 7 includes the subject matter of Examples 1-6, wherein the universal data schema requires structured data files with a K-1 exchange certificate including at least: (i) a package identifier that is a unique identifier associated with a structured data file, and (ii) a certification identifier that is a unique identifier indicating that the structured data file has been certified.
Example 8 includes the subject matter of Examples 1-7, wherein the universal data schema includes multiple versions, and the schema validation subsystem is to validate a version of the one or more structured data files.
Example 9 includes the subject matter of Examples 1-8, further comprising an API gateway to receive one or more structured data files.
Example 10 includes the subject matter of Examples 1-9, wherein the registration manager is to require identification of a legal entity as either a K-1 producer or a K-1 receiver to be registered users in the database.
Example 11 includes the subject matter of Examples 1-10, wherein the registration is to enforce a legal entity type, including taxpayer identification number, and contact information for a legal entity account to be created as a registered user in the database.
Example 12 includes the subject matter of Examples 1-11, further comprising a publishing engine, on one or more processors, to publish one or more structured data files based on one or more connections between one or more K-1 producers and one or more K-1 receivers.
Example 13 is a computerized method for digital tax data exchange. The method includes validating one or more structured data files are formatted in accordance with a universal data schema based on entity-specific data requirements. The plurality of structured data files relate to K-1 producers, which are financial entities that issue schedule K-1 documents and K-1 receivers, which are persons to whom schedule K-1 documents are issued. In response to validating the one or more structured data files, the method includes validating includes generating a validation certificate that is associated with the one or more structured data files. The method includes registering a plurality of legal entities as a K-1 producer and/or a K-1 receiver as registered users in a database, wherein the registering step includes a digital identity validation process. The method also includes making connections between one or more K-1 producers and one or more K-1 receivers to establish access control therebetween. The access control between connected K-1 producers and K-1 receivers provides data access to one or more of each other's structured data files.
Example 14 includes the subject matter of Example 13, wherein the validating step rejects a data file inconsistent with the universal data schema.
Example 15 includes the subject matter of Examples 13-14, wherein the universal data schema requires structured data files with at least: (i) K-1 data; and (ii) a K-1 exchange certificate.
Example 16 includes the subject matter of Examples 13-15, wherein the (i) K-1 data; and (ii) an K-1 exchange certificate are bundled into a single data file.
Example 17 includes the subject matter of Examples 13-16, wherein the universal data schema further requires one or more attachment files.
Example 18 includes the subject matter of Examples 13-17, wherein the universal data schema requires structured data files with K-1 data including at least: (i) a producer identification; (ii) a recipient identification; (iii) a tax year; (iv) a form type; and/or (v) an issuance type.
Example 19 includes the subject matter of Examples 13-18, wherein the universal data schema requires structured data files with a K-1 exchange certificate including at least: (i) a package identifier that is a unique identifier associated with a structured data file, and (ii) a certification identifier that is a unique identifier indicating that the structured data file has been certified.
Example 20 includes the subject matter of Examples 13-19, wherein the universal data schema includes multiple versions, and the schema validation subsystem is to validate a version of the one or more structured data files.
Example 21 includes the subject matter of Examples 13-20, further comprising an API gateway to receive one or more structured data files.
Example 22 includes the subject matter of Examples 13-21, wherein the registering step includes requiring identification of a legal entity as either a K-1 producer or a K-1 receiver to be registered users in the database.
Example 23 includes the subject matter of Examples 13-22, wherein the registering step includes enforcing a legal entity type, including taxpayer identification number, and contact information for a legal entity account to be created as a registered user in the database.
Example 24 includes the subject matter of Examples 13-23, further comprising publishing one or more structured data files based on one or more connections between one or more K-1 producers and one or more K-1 receivers.
Example 25 is one or more non-transitory, computer-readable storage media comprising a plurality of instructions stored thereon that, in response to being executed, cause a computing device to validate one or more structured data files are formatted in accordance with a universal data schema based on entity-specific data requirements. The plurality of structured data files relate to K-1 producers, which are financial entities that issue schedule K-1 documents and K-1 receivers, which are persons to whom schedule K-1 documents are issued. In response to validating the one or more structured data files, the instructions generates a validation certificate that is associated with the one or more structured data files. There are instructions to register a plurality of legal entities as a K-1 producer and/or a K-1 receiver as registered users in a database, which includes a digital identity validation process. There are also includes to make connections between one or more K-1 producers and one or more K-1 receivers to establish access control therebetween. The access control between connected K-1 producers and K-1 receivers provides data access to one or more of each other's structured data files.
Example 26 includes the subject matter of Example 25, wherein there are instructions to reject a data file inconsistent with the universal data schema.
Example 27 includes the subject matter of Examples 25-26, wherein the universal data schema requires structured data files with at least: (i) K-1 data; and (ii) a K-1 exchange certificate.
Example 28 includes the subject matter of Examples 25-27, wherein the (i) K-1 data; and (ii) an K-1 exchange certificate are bundled into a single data file.
Example 29 includes the subject matter of Examples 25-28, wherein the universal data schema further requires one or more attachment files.
Example 30 includes the subject matter of Examples 25-29, wherein the universal data schema requires structured data files with K-1 data including at least: (i) a producer identification; (ii) a recipient identification; (iii) a tax year; (iv) a form type; and/or (v) an issuance type.
Example 31 includes the subject matter of Examples 25-30, wherein the universal data schema requires structured data files with a K-1 exchange certificate including at least: (i) a package identifier that is a unique identifier associated with a structured data file, and (ii) a certification identifier that is a unique identifier indicating that the structured data file has been certified.
Example 32 includes the subject matter of Examples 25-31, wherein the universal data schema includes multiple versions, and the schema validation subsystem is to validate a version of the one or more structured data files.
Example 33 includes the subject matter of Examples 25-32, further comprising instructions for an API gateway to receive one or more structured data files.
Example 34 includes the subject matter of Examples 25-33, wherein there are instructions to require identification of a legal entity as either a K-1 producer or a K-1 receiver to be registered users in the database.
Example 35 includes the subject matter of Examples 25-34, wherein the registration is to enforce a legal entity type, including taxpayer identification number, and contact information for a legal entity account to be created as a registered user in the database.
Example 36 includes the subject matter of Examples 25-35, further comprising instructions to publish one or more structured data files based on one or more connections between one or more K-1 producers and one or more K-1 receivers.
This application claims the benefit of U.S. Provisional Application No. 63/271,467, filed Oct. 25, 2021 for a “Method and System for Digital Tax Document Exchange” and U.S. Provisional Application No. 63/233,962, filed Aug. 17, 2021 for a “K-1 Exchange,” both of which are hereby incorporated by reference in their entireties.
| Number | Date | Country | |
|---|---|---|---|
| 63233962 | Aug 2021 | US | |
| 63271467 | Oct 2021 | US |
