RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63/271,467, filed October 25, 2021 for a “Method and System for Digital Tax Document Exchange” and U.S. Provisional Application No. 63/233,962, filed August 17, 2021 for a “K-l Exchange,” both of which are hereby incorporated by reference in their entireties.

BACKGROUND

[0002] Each year in the United States, roughly 40 million Schedules KI are distributed from about 7.5M million flow-through entities. Flow-through entities include Partnerships, S Corporations and Trusts. A Schedule KI 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. FIG. 1 shows an example, blank KI face page, which contains the majority of the structured information. Each of the highlighted boxes (Part I, Boxes A- D, Part II, Boxes E-M, and Part III, Boxes 1-20) in FIG. 1 follow a structured format. However, one complexity is that some highlighted boxes can have too much detail to fit on this face page, so the remaining information exists in the unstructured, whitepaper sections of the document. In addition, the face page of the K-l only addresses federal income tax. Whitepaper statements and other state tax forms will be included in K-l packets to provide state and international filing responsibilities.

[0003] FIG. 2A shows an example in which Box 16 of a KI face page is filled with foreign transactions A-F, along with a note of "STMT." The note "STMT" means that foreign transaction information on the face page is incomplete, and thus, a user would need to find the corresponding section in the whitepapers to get the remaining details regarding Box 16 (foreign transactions). FIG. 2B shows an example portion of a whitepaper corresponding to Box 16 (foreign transactions) filling in details for remaining foreign transactions G-M.

[0004] 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 KI packets, each of the 7.5M schedule K-l 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 KI packet, typically in PDF form, and hand-typing information into their processing software.

[0005] 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 September 16, 2019 for a “Machine Learning System for Summarizing Tax Documents with Non-Structured Portion,” which is hereby incorporated by reference. Al-powered machine-learning solutions have made great strides towards extracting much of the data provided in a Schedule K-l, but it is not exact and it is often not everything a specific partner needs to meet its filing requirements.

[0006] The problem is further exacerbated as a result of the tiered partnership structure. Many schedule K-l 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-l packet that may provide the same data element reported multiple times vs. the aggregate reporting for all tiers within one summary.

[0007] Therefore, there is a need for a system that overcomes one or more of these issues.

SUMMARY

[0008] 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-l producers, which are financial entities that issue schedule K-l documents and K-l receivers, which are persons to whom schedule K-l 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-l producer and/or a K-l 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-l producers and one or more K-l receivers to establish access control therebetween. The access control between connected K-l producers and K- 1 receivers provides data access to one or more of each other’s structured data files.

[0009] 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-l producers, which are financial entities that issue schedule K-l documents and K-l receivers, which are persons to whom schedule K-l 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-l producer and/or a K-l 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-l producers and one or more K-l receivers to establish access control therebetween. The access control between connected K-l producers and K-l receivers provides data access to one or more of each other’s structured data files.

[0010] 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-l producers, which are financial entities that issue schedule K-l documents and K-l receivers, which are persons to whom schedule K-l 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-l producer and/or a K-l 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-l producers and one or more K-l receivers to establish access control therebetween. The access control between connected K-l producers and K- 1 receivers provides data access to one or more of each other’s structured data files.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] 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.

[0012] FIG. 1 is an example blank K-l face page;

[0013] FIG. 2 A is an example detailed view of Box 16 of the K-l face page of FIG. 1 filled in with certain information;

[0014] FIG. 2B is an example portion of a whitepaper corresponding with certain details corresponding to Box 16 shown in FIG. 2A;

[0015] FIG. 3 is a simplified block diagram of at least one embodiment of various components and environments of the K-l exchange;

[0016] FIG. 4 is a simplified block diagram of at least one embodiment of an .K-1X document of the K-l exchange;

[0017] FIG. 5 is a simplified block diagram showing example components of the .K- IX document shown in FIG. 4 according to an embodiment of this disclosure;

[0018] FIG. 6 is an example XML file representing the data portion of the .K-1X document shown in FIG. 4 according to an embodiment of this disclosure;

[0019] FIG. 7 is an example XML file representing the certificate portion of the .K-1X document shown in FIG. 4 according to an embodiment of this disclosure;

[0020] FIG. 8 is an example XML schema definition file for the certificate portion of the .K-1X document shown in FIG. 4 according to an embodiment of this disclosure;

[0021] FIG. 9 illustrates an example K-l schema organization according to an embodiment of this disclosure;

[0022] FIG. 10 is an example XML schema definition file for the attachments portion of the .K-1X document shown in FIG. 4 according to an embodiment of this disclosure;

[0023] FIG. 11 is an example XML schema definition file for the data types portion of the .K-1X document shown in FIG. 4 according to an embodiment of this disclosure;

[0024] FIG. 12 illustrates an example K-l schema organization for an example partnership folder according to an embodiment of this disclosure; [0025] FIG. 13 illustrates an example K-l schema organization for example data types according to an embodiment of this disclosure;

[0026] FIG. 14 illustrates an example K-l schema organization for header information in the .K-1X document according to an embodiment of this disclosure;

[0027] FIG. 15 illustrates an example K-l schema organization for certification information in the .K-1X document according to an embodiment of this disclosure;

[0028] FIG. 16 is a simplified block diagram showing an example K-l exchange according to an embodiment of this disclosure;

[0029] FIG. 17 is a simplified block diagram showing an example environment of the K-l exchange during operation according to an embodiment of this disclosure;

[0030] FIG. 18 is a simplified flow diagram of at least one embodiment of a method for recipient information reporting with the K-l exchange;

[0031] FIG. 19 is a simplified flow diagram of at least one embodiment of a method for registering and verifying legal entities with the K-l exchange;

[0032] FIG. 20 is a simplified flow diagram of at least one embodiment of a method for registering and verifying legal entities with the K-l exchange;

[0033] FIG. 21 is a simplified flow diagram of at least one embodiment of a method for electronically signing certain documents for the K-l exchange; and

[0034] FIG. 22 is a simplified block diagram of at least one embodiment of the K-l exchange interacting with an external application I process through an API.

DETAILED DESCRIPTION OF THE DRAWINGS

[0035] 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.

[0036] 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).

[0037] 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).

[0038] 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.

[0039] 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-l and their respective data needs. These legal entities include: [0040] - Corporation

[0041] - Disregarded Entity

[0042] - Estate

[0043] - Fiduciary

[0044] - Grantor Trust

[0045] - Individual

[0046] - Nominee

[0047] - Partnership [0048] - Individual Retirement Account

[0049] - S Corporation

[0050] - Trust

[0051] - Exempt Organization

[0052] - Limited Liability Company

[0053] - Limited Liability Partnership

[0054] - Foreign Government

[0055] 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-l Exchange. For example, K-l receivers could post out to the K-l Exchange all of their demographic information, and that data could then be automatically pulled into the world of the K-l producers, who would then use it to create K-ls that have the correct demographic information on them. Additionally, K-l receivers can provide their composite and withholding eligibility information so that the K-l producers automatically receive it and have all of the information that they need to properly handle state and local taxes.

[0056] Once the K-l producers have all the information that they need to do their work, they can then complete their K-ls and provide all of the necessary federal, state, international, capital, and basis details seamlessly and digitally to the K-l receivers. This enables having all of that data automatically show up in the correct spot with no human data entry necessary for the K-l receivers.

[0057] Referring now to FIG. 3, an embodiment of a system 100 for K-l exchange with one or more servers 102 in communication with multiple computing devices 104 over a network 106 is shown. In the example shown, multiple computing devices 104 are associated with K-l producers; some computing devices 104 are associated with K-l recipients; and some computing devices 104 are associated with an external application I process that access the servers 102 via an API gateway. Although five computing devices 104 are shown for purposes of example, but more or less could be in communication with the servers 102. Typically, hundreds or thousands of computing devices 104 may be in communication with the server 102. Likewise, even though a single server 102 is shown for purposes of example, more servers 102 could be provided depending on the circumstances. For example, the server 102 could be a cloud-based platform with a plurality of servers accessible through the network 106. Embodiments are also contemplated in which the server 102 could establish a cloud-based platform (e.g., SaaS platform) through which computing devices 104 may send messages using an app running on the Android™ operating system by Google, Inc. of Mountain View, California and/or an app running on the iOS™ operating system by Apple Inc. of Cupertino, California on which software has been installed to perform one or more actions according to an embodiment of the present disclosure. Although the system 100 may be a cloud-based platform accessible by the computing devices 104, in some embodiments one or more features of the server 102 could be performed locally on the computing devices 104 depending on the circumstances.

[0058] 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. [0059] In an illustrative embodiment, the server 102 establishes an environment during operation to provide one or more features of a K-l Exchange 108. In the example shown, the K-l 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-l 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-l 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.

[0060] Digital K-l (.K- IX file)

[0061] As discussed herein, the K-l Exchange 108 is configured to generate, at least in part, a plurality of structured data files representing K-l 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-l schema. The .K1X documents provides a digital, standardized specification for the K- 1 statement.

[0062] To understand the digital exchange of data between K-l Producers and K-l 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-l 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-l,” is the answer to provide the standardization for K-ls.

[0063] Referring now to FIG. 4, there is shown an example .K1X document. In some embodiments, at its core, the .K1X document is a combination of structured data files in json (JavaScript object notation) or xml (extensible markup language) format adhering to a defined schema (the K- 1 schema) along with the option to provide additional attachments with supporting information outside of the K-l schema. In the example shown, the file extension of .K1X is the indicator for a consuming application to know what specification to expect, which can then be viewed as a zip file 400 to become uncompressed and the contents 402 can be unpacked for processing. In the example shown, the contents 402 include KI Attachments 404, Kldata.json 406, and Klexchangecert.json 408. Of course, the “.K1X” extension is provided for purposes of example, but other naming schemes for the extension could be used.

[0064] FIG 5 illustrates an example high-level overview of the contents 402 that may make up the composition of the uncompressed .K1X document 110. In the example shown, the .K1X document 110 comprises K-l data 406, K-l exchange data 408, and K-l attachments 404. Each of the components 406, 408, 404 will be discussed in turn.

[0065] In some embodiments, the K-l 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-l data 406 is the core component of the .K-1X document 110, which contains the necessary, structured information for the recipient for their K-l reporting. In some embodiments, the K-l data 406 includes one or more of the following:

[0066] • Producer 500 - This contains the information of who the K-l Producer is issuing the K-l, which includes the Legal Entity Name, Address, and Tax ID.

[0067] • Recipient 502 - This contains the information of who is receiving the K-

1 which includes the Legal Entity Name, Address, and Tax ID.

[0068] • Tax Year 504 - This specifies which Tax Year the K-l corresponds to

(i.e. - 2020). This is required and important as it will drive which version of the K-l schema to validate the K-l data file against since data points and requirements of a K-l is subject to change from year to year.

[0069] • Form Type 506 - This specifies which type of K-l (1065, 1120-S, or

1041) is being issued, similar to the Tax year data element it is required because it will drive which version of the K-l schema to validate the Kldata.json file against since data points and requirements of each K-l form type is subject to change from year to year. [0070] Issuance Type 508 - Throughout the year a producer of a K-l may report multiple times K-l data to assist their receivers in their own tax planning activities. The issuance types for most K-ls 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.

[0071] The data file 402 can also contain K-l 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-l files distributed to a receiver. For example, the producing entity may deliver Federal K-l data 510 only early on in the process, then once state information 512 is finalized they can build a separate .Klx 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. FIG. 6 illustrates an example XML file representing the data file 402. The contents of the data file 402 will adhere to a K-l Schema, an embodiment of which is outlined herein.

[0072] Referring again to FIG. 5, some embodiments of the K-l exchange certificate 408 of the .K1X document 110 include a package ID 518 and a certification ID 520. The K-l exchange certificate 408 portion of the .K1X document 110 may be in .XML or .JSON file format; however, other formats could be used depending on the circumstances. Part of what makes the .K1X document 110 an official .Klx file is the importance of validation and “certifying” it through the K-l Exchange 108. That certification solves a technical challenge that exists today so that tax professionals will trust the source of the data and that the .K1X document 110 is complete, accurate, valid, etc. Secondarily, to protect the value of the .K1X document 110 and its downstream use for consumption in tax analysis and management tools, such as those offered by Crowe LLP of Chicago, Illinois as part of the K-l Advantage™ ecosystem. In some embodiments, the K-l exchange certificate 408 includes the following components:

[0073] • K-l Exchange Package ID 518 - Unique ID (GUID, Globally Unique

Identifier) stored in the K-l Exchange 108 that this file is associated to.

[0074] • K-l Exchange Certification ID 520 - Unique ID (GUID, Globally Unique

Identifier) stored in the K-l Exchange 108 that this file has been validated and certified “approved” by the K-l Exchange 108 to be used for downstream consumption. [0075] The creation of the K-l exchange certificate 408 and how the certificate 408 is added to the .K1X document 110 is explained herein. An example K-l exchange certificate 408 is shown in FIG. 7.

[0076] The .K1X document 110 may include K-l attachments 404, which is an optional component of the Digital K-l that may provide additional information that is outside the core K-l Data file 406 that is supporting information in regards to the K-l schema. An example of this might be the actual PDF(s) of the K-ls that were filed with the taxing jurisdictions to ensure the recipient as both their digital and pdf/electronic copy of their K-ls. 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.

[0077] K-l Schema

[0078] At its highest level the K-l 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-l. 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-l in either a resulting .JSON file or as mentioned previously in the Digital K-l file section, an .XML file (e.g. - KIData.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).

[0079] In some embodiments, the K-l 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-l data 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. [0080] 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 FIG. 8, the schema definition files include a definition at the top of each file. In this example, this ensures all schemas fall under the common Klx namespace and are hosted at the K-l Advantage public website. The schema is made publicly available so all parties in the K-l ecosystem have access to the standard expectation of what should be contained in a digital k-l file. The next layer down of the K-l Schema is the main structure, which in some embodiments may be organized as shown in FIG. 9. In the example shown, the K-l Schema may be organized as a common folder 900, a partnership folder 902, a SCorporation folder 904, a trust folder 906, a KIData.xsd file 908, a KlExchangeCertification.xsd 910 file, and a KIHeader.xsd file 912. Each of these is discussed in turn.

[0081] • Common 900 - This folder, in some embodiments, contains common data types that can be re-used, define data constraints, and nest complex structures across the main schemas that contain the data element definitions. In some cases, this folder may include a KI Attachment. xsd file, which is a base complex type defining the structure of specifying what attachments are located in the “Attachments” 404 portion of the .K1X document 110 outside of the K-l data portion 406. An example KlAttachment.xsd file is shown in FIG. 10. In some cases, the common folder 900 may include a KIDataTypes.xsd file, which is a collection of base data and complex types that are references for elements defined in later schemas. An example of this file with example types that can found in the file is shown in FIG. 11.

[0082] • Partnership 902, S-Corporation 904, and Trust 906 folders - For each K-

1 type the schema supports (e.g., 1065 Partnerships, 1120-S S-Corporations, and 1041 Trusts) there are specific data elements and structures that pertain to them, but as mentioned in the previous point there is still the common elements shared across each type. FIG. 12 is an example showing the underlying contents of an example Partnership folder 902, where there is a root element schema file, PartnershipKIData.xsd, supporting schema files specific to each jurisdiction (i.e. - PartnershipKlData_California.xsd), and common schema files that is re-used for describing different elements with the same data structure (i.e. - StateEquivalent.xsd is a common complex type used for jurisdictions that don’t have any formal K- 1 reporting but require a common set of data reported for them, such as the states of Florida and Michigan). [0083] • KIData.xsd 908 - This is the main schema file that brings everything together and tied back to the design pattern mentioned earlier in the resulting xml file defines the global element of “KI Data” in which every other element is nested under. FIG. 13 shows example components of the KIData type. In the example shown, the starting point is the KIHeader, which as explained herein, is a choice between PartnershipKIData, SCorporationKIData, or TrustKIData, then capped off with the KlAttachments element in accordance with the KlAttachmentType previously mentioned.

[0084] • KIHeader.xsd 912 - This portion of the K-l schema defines the high level attributes of the contents of the KIData file 406, and can almost be thought of like a “cover letter” so a consumer knows what to expect in the result detailed sections of the K-l Data document 110. An example of the K-lHeader.xsd 912 is shown in FIG. 14. The Timestamp and IP data elements are important for traceability to understand when the K- 1 data file was created and where at. KIProducerEntity and KIRecipientEntity are the elements that describe the parties engaged in the K-l data file (producer and receiver). TaxYear drives what tax reporting year the data is subject to. IssuanceType, FinalKl, AmendedKl are all attributes describing the “State” of the K-l. For example, the IssuanceType may be classified as “Estimate”, which indicates to the receiver of the data that this is not final and the actual data comes later in the compliance season.

[0085] • KlExchangeCertification.xsd 910 - In some embodiments, the final high- level schema file is not an element tied to the KIData document 110, but a separate global/root element to create a separate XML (or j son) file ensuring the digital k- 1 file created has been submitted, validated, and transmitted via the K-l exchange 108. In the example shown in FIG 15, there are only two attributes required in this schema. The first is the KlExchangePackagelD, which is a globally unique identifier (GUID) representing the record id of the .K1X document 110 stored on the K-l Exchange 108, the K-l Exchange API 120 has an endpoint to validate the ID is a record in the system 100. The second is the KlExchangeCertificationlD, which is another GUID representing a record in the K-l Exchange that can be validated via an API endpoint 120, but also provide resulting information of the .K1X document 110 passing validation and certified as accessible via the K-l Exchange 108.

[0086] In some embodiments, the K-l 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-ls 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-l schema and subsequently the .K1X documents 110 and K-l Exchange 108 is designed in a manner to support different versions coexisting in the system. For example, an initial version of the K-l 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-l 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-ls had plans/operations set forth expecting the prior version and the newly introduced minor version does not apply to them anyway.

[0087] 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 mechanic s/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.

[0088] • Version number scheme - In some embodiments, the version number scheme could be the Tax Year for which the schema applies (YYYY), the lower-case version initial (v), and the two-digit version number (N.N). An example of this scheme is 2020v.l.0.

[0089] • Validating Schema Versions - In some embodiments, throughout the year, multiple versions of the K-l Schema files are subject to changes and released. Depending on if the schema change is major or minor; processing applications (e.g., - K-l Navigator™, K-l Exchange™) may not require the schema version found in the data to match the schema version used by the creator of the digital k-l during validation. There is always one active validating schema version for the digital K-l for a Tax Year. In rare circumstances, there may be more than one active validating schema version. In some cases, there may be minor schema changes. When a revised schema changes the increment for the minor number, a processing application will continue to accept digital k-ls composed using previous schema versions. When the minor number is changed, the processing applications decide for themselves whether they need to use the new version or not based on what is included in their software and what changes were made to the Schemas. Consider an example if the change affects a form or field not supported or applicable then electing to not use the newest version is an option. For example, if the current schema version is 2020vl.0 and the schema change is minor, the K-l Advantage™ ecosystems will assign the new number as 2020vl.l. The active validating schema version is 2020vl.l. A processing application, such as the K-l Exchange 108 will continue to accept digital k-l files composed using either version 2020vl .0 or 2020vl .1. Both versions will have a validation path to get their K-l Exchange certificate file accompanied in the .Klx file. In some cases, there may also be major schema changes. When the K-l advantage ecosystem issues a revised k-l schema and changes the increment for the major number, all k-l data files in the .Klx document 110 must be composed using the new version number. Consider an example in which the current version is 2020vl.l and it is decided by the K-l schema owners, it can no longer accept digital k-ls composed using schema version 2020vl.l (or 2020vl.0), and it will assign the new number 2020v2.0. The active validating schema version is 2020v2.0. Back to the K-l Exchange 108 as a processing application, a digital k-l submitted with 2020vl.l (or 2020vl.0) will be rejected for using an unsupported schema version and not receive the K-l exchange certification file.

[0090] K-l Exchange

[0091] FIG. 16 shows a high-level example of the K-l Exchange 108 as part of an example ecosystem, with a secure API gateway 120 facilitating all (or at least a portion) of the interaction. In some cases, certain tools, such as K-l Navigator™, may have native capabilities embedded in them to abstract a more detailed integration with the K-l Exchange 108, that otherwise can be accomplished through custom development to interact with other tools and processes.

[0092] FIG. 17 illustrates example components of the K-l Exchange 108 according to an embodiment. In the example shown, the K-l Exchange includes a registration manager 112, a connections subsystem 114, a universal information request 116, a publishing engine 118, and an API gateway 120. Depending on the circumstances, some of these modules could be optional and other modules or functionality could be provided. [0093] User and Legal Entity Registration and Verification

[0094] The registration manager 112 is configured to register users with the K-l Exchange 108. FIG. 18 illustrates example actions that could happen during the user registration process. As shown, the registration manager 112 could be configured to create a user account (block 1800), validate the email provided by the user (block 1802), setup a two-factor authentication (block 1804), and legal entity registration / associate (block 1806). In some cases, the following attributes may to be provided for the registered user in their profile:

[0095] o Email (used for login ID)

[0096] o First and Last Name

[0097] o Password. In some cases, there could be password requirements, such as using at least 8 characters, 1 lowercase letter, 1 uppercase letter, 1 number, 1 symbol, does not contain username, first name, or last name, password expired every 45 days, locked out after 5 unsuccessful attempts, and/or automatically unlocked after 30 minutes

[0098] 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-l Exchange 108 to conclude the validation of a legitimate email address provided by the user (block 1802).

[0099] To complete the user registration feature, users may be required to setup two factor authentication (block 1804) via a K-l Exchange identity management service. The K-l Exchange 108 may run through the following example steps to setup two factor authentication and additional security items.

[00100] o User logins with their provided email and password from the registration laid out above.

[00101] o A challenge question must be selected with a provided answer to use in case of a forgotten password.

[00102] o The user will choose a security image that will appear each time logging into the K-l Exchange to give the user feedback of assurance they are not a fraudulent application.

[00103] o The user chooses from a list of options to facilitate the two-factor process. There may be multiple two-factor options, such as one or more of the following, Okta Verify - verify via the Okta Verify app on the user’s device; Google Authenticator - verify via the Google Authenticator app on the user’s device; SMS Authentication - verify via a text code sent to the user’s phone; Email Authentication - verify via a code emailed to the user’s email.

[00104] 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-l Exchange 108 of which they will administer, or request association to existing legal entities on the K-l exchange 108 so they can be added as a contact to help administer activities for that legal entity.

[00105] In order to interact either as a producer or receiver of K-ls 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-l 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 FIG. 19, to register a legal entity in the K-l exchange 108, one or more of the high-level sequence of steps are conducted. The legal entity registering for the K-l Exchange will specify if they are registering as either a producer, receiver, or both of K-ls as this will be important to drive additional functional capabilities for the legal entity downstream within the K-l Exchange 108 (block 1900). If registering as a producer, this will ensure/enforce the legal entity type in the next step (block 1902) should be a Partnership, S -Corporation, or Trust. Next, the legal entity information is provided (block 1902). The legal entity type will be selected (e.g., one of the prior fifteen options mentioned earlier in the document). The name, taxpayer identification number (SSN for individuals, EIN for non-individuals), and primary address / legal domicile may be provided. Depending on the circumstances, other information may be requested through the legal entity registration process.

[00106] 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.

[00107] 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.

[00108] Connection discovery between Producing and Receiving Legal Entities

[00109] 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.

[00110] Producers “Discover” their Receivers on the K-l Exchange 108 and receivers verify/accept the connection. A legal entity that intends to produce and publish K-ls to their recipient group can request to connect/follow their recipients if those recipients have already registered on the K-l 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:

[00111] • Legal Entity Type (one of the prior fifteen options mentioned earlier in the document) [00112] • Taxpayer Identification Number (SSN for individuals, EIN for nonindividuals)

[00113] • Name of Legal Entity

[00114] Once the recipient is found the K-l 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-l information. The recipient receives this request in their K-l 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-l to, if a connection has not already been requested and accepted from the recipient themselves.

[00115] Receivers “Discover” their Producers on the Exchange 108 and producers verify/accept the connection. A legal entity that intends to receive K-ls from a portfolio of producers can request to connect with these producers if they have already registered on the K-l exchange. Receivers discover the producers with the same unique information that the producers registered with, such as:

[00116] • Legal Entity Type (one of the three producer types, Partnership, S-

Corporation, or Trust)

[00117] • Taxpayer Identification Number (EIN)

[00118] • Name of Legal Entity

[00119] Once the producer is found within the K-l 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-l information from the producing entity. The producer receives this request in their K-l 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.

[00120] Recipient Information Reporting (Demographic, Composite, Withholding} [00121] 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-l information for each recipient an information request is typically conducted of their recipients. On the flip side, recipients on the K-l 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-l 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.

[00122] In some embodiment, the recipient information request could include one or more of the following components:

[00123] • Demographics - Each legal entity receiving K-l information via the K-l exchange answers a series of questions relating to Federal and applicable State jurisdictions. The questions are logic-based with a series of dynamic rules applied to them to ensure question is applicable to one of the 15 entity types of recipients.

[00124] • Composite - This is a series of questions for the recipient to map out their election and eligibility to be included on a composite filing that is handled by their producing flow-through entity (i.e. - State of Michigan Partnership Composite Return). For each jurisdiction the recipient could be subject to composite tax based on their investment portfolio (activity of the producers), they will be required to answer three basic questions, which help determine composite eligibility for that recipient, producer, jurisdiction intersection: (i) Apart from your interest in your investments, do you have an income tax filing requirement in the state? (ii) If yes, is all that income derived from flow- through investment entities? (iii) Do you want to be included in the composite filing if eligible? The answers to the previously mentioned questions are then used as inputs to determine final composite eligibility.

[00125] • Composite affidavits with electronic signature - For each jurisdiction the recipient has elected to be on the composite return, some jurisdictions require a signed affidavit or multiple documents. These documents are automatically populated for each producer and jurisdiction combination the recipient has elected to from the composite portion of the information request.

[00126] • Non-Resident Withholding and Mandatory Composite exemption forms with electronic signature - For each jurisdiction the producers may be responsible for either executing non-resident withholding or subject to mandatory inclusion of a recipient on the producer’s composite return there may be an option to collect an exemption form for that jurisdiction and recipient type. Recipients (if applicable to their tax situation) can electronically sign these documents which are automatically populated with the recipient information and producer information where the exemption could be executed.

[00127] FIG. 20 illustrates example electronic signature functionality for State & Local Tax Composite/Withholding documents. In some embodiments, this electronic signature functionality could work similarly for a composite affidavit form and/or a nonresident withholding exemption form. Consider an example in which a recipient is a nonresident of Georgia, and will be receiving K- 1 s from producers of three different entities with activity in Georgia and the entity files a composite return in Georgia. The recipient wants to be included on all three of the entities composite return, but before the final determination of their eligibility to be included they need to provide a signed Georgia CR- AFF form for each producer’s records to have on file. The K-l exchange 108 simplifies this process through the functionality outlined herein where the recipient views a generic/populated CR-AFF Form, then confirms which producer entities will receive the form, and the K-l Exchange 108 conducts electronically signing the document on behalf of the receiver’s confirmation to each producing entity turning in this example what was one action for the user into three required deliverable outputs. FIG. 21 illustrates this example. Once the information request is complete by the recipient, the request is submitted for final validation to confirm an appropriate submission. The submitted request is not available for producers to subscribe to pull the information down into their respective processes and tooling as needed.

[00128] Digital K-l Publishing to the Exchange by Producers

[00129] As producers of K-ls, the key feature for them in the K-l Exchange is the ability to publish their generated and/or construct their Digital K-l files so they are transmitted for each recipient for whom they are obligated to report. The following outlines how the K-l Exchange 108 facilitates this publishing. The K-l Exchange 108 user securely connects/authenticate, and navigates to the specific Account/Legal-Entity combination for the K-ls they wish to publish. In some embodiments, if the option to publish digital K-l(s) information to the Exchange 108 is chosen, the user must specify if they already have a digital K-l constructed, or need the assistance of the K-l exchange to package up the component. If they require the K-l exchange to construct the digital K-l, they complete the following steps: (i) specify issuance type (Estimate, Draft, Final), (ii) upload their K-l Data (.XML or .JSON) file(s) adhering to the K-l schema for each K-l receiver they intend to publish, (iii) upload any additional PDF attachments (i.e. the physical K-l files) for each K-l receiver they intend to publish. In some cases, it is possible the producer does not yet have the ability to create a K-l Data file and only has PDFs of K-ls. In this event, they can still use the K-l Exchange 108 for distribution, but their K-l PDFs will be sent to the K-l Reader for extraction, the results are then parsed to a usable K-l Data format to its best abilities. Once the Digital K-ls are uploaded and constructed, the next step will be to validate their contents. For each Digital K-l that passes the required validation, the K-l Exchange 108 will generate a K-l Exchange Certificate file in either XML or JSON to match the K-l Data file format. Having this file will give the downstream receiver the guarantee their Digital K-l has gone through the proper quality checks for safe consumption. After the producer completes the publishing portion for the Digital K-ls, the K-l Exchange 108 manages any and all notifications to inform the receivers on the K-l Exchange 108 their digital K-ls are available to the specified receiver group the producer is connected to.

[00130] Digital K-l Transmission from the Exchange for Receivers

[00131] As receivers of K-ls, the ability to receive their Digital K-ls so it can be consumed into their respective tax workpapers or application of choice. In some embodiments, the K-l Exchange 108 facilitates receiving the Digital K-l with one or more of the following steps: (i) the K-l Exchange user securely connects/authenticates, and navigates to the specific account/legal-entity combination for the K-ls they wish to retrieve; (ii) once they have landed on the desired legal entity’s dashboard, they will be able to view which K-ls they are expecting from connected producers, of those connections the ones that have gone through the functionality to publish K-ls will have a notification they are “ready” for the receiver to consume the Digital K-l; (iii) depending on the destination of the Digital K-l there will multiple options for the receiver to choose from, such as downloading a PDF of K-l and any other attachments (if provided), downloading the entire Digital K-l (.K-1X file), and/or if the receiver is a user of a downstream tool, they may transfer directly into a downstream tool.

[00132] API Connectivity via general API Gateway & Developer SDK

[00133] In some embodiments, one or more functions of the K-l Exchange 108 is exposed through APIs 120 (Application Programming Interfaces) through a controlled gateway. Fig. 22 shows a high-level diagram showing the mechanics of an external application / process 104 interacting with the K-l Exchange API 120 with endpoint resources (Accounts, Connections, K-lPackages, Certifications) that are accessible according to an embodiment. In some cases, the API 120 uses a REST based design, leverages the JSON data format for sending and receiving data, and relies upon HTTPS for transport. The responses from the K-l Exchange gateway 120 are through HTTP codes and if an error occurs, included error details are provided in the response body. In some embodiments, an aspect of the K-l Exchange API 120 is that it supports Cross-Origin Resource Sharing (CORS) which allows use of the API 120 directly from another web application. The API 120 may be secured by enforcement of TLS (SSL or HTTPS) on all communication to API endpoints. In some cases, the API calls must have a valid access token passed either in the request header or as a query parameter passed in the call.

[00134] In some embodiments, K-l 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-l 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.

[00135] After an access token is obtained, one or more of the following API endpoints could be available in the K-l Exchange 108 for programmatic interaction as opposed to interacting via direct, end-user, browser-based experiences. In some cases, not all K-l 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-l package could be transmitted via the exchange 108. The endpoints shown in FIG. 22 are for purposes of example, but APIs and endpoints are always evolving, and more endpoints and variations of these are subject to change depending on the circumstances. In some cases, the endpoints may be accessed through the API 120 as follows:

[00136] • Accounts 2200 - For the provided access token, supplies a collection of accounts that can be taken action via the API.

[00137] • Entities 2202 - Legal entities registered on the exchange that belong to a specified account.

[00138] • Connections 2204 - connections established with other legal entities registered on the K-l exchange with a provided legal entity in either a producer or receiver relationship. [00139] • K-l Packages 2206 - Digital K-l files either produced and posted to the

K-l exchange or digital k-l files that have been posted and can be download from the receiver perspective.

[00140] In some cases, there may be a K-l 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-l Certification .XML or .JSON file to ensure the authenticity and validate of the Digital K-l about to be processed.

[00141] EXAMPLES

[00142] 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.

[00143] 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-l producers, which are financial entities that issue schedule K-l documents and K-l 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-l producer and/or a K-l 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-l producers and one or more K-l receivers to establish access control therebetween. The access control between connected K-l producers and K-l receivers provides data access to one or more of each other’s structured data files.

[00144] 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.

[00145] Example 3 includes the subject matter of Examples 1-2, wherein the universal data schema requires structured data files with at least: (i) K-l data; and (ii) a K-l exchange certificate.

[00146] Example 4 includes the subject matter of Examples 1-3, wherein the (i) K-l data; and (ii) an K-l exchange certificate are bundled into a single data file. [00147] Example 5 includes the subject matter of Examples 1-4, wherein the universal data schema further requires one or more attachment files.

[00148] Example 6 includes the subject matter of Examples 1-5, wherein the universal data schema requires structured data files with K-l 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.

[00149] Example 7 includes the subject matter of Examples 1-6, wherein the universal data schema requires structured data files with a K-l 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.

[00150] 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.

[00151] Example 9 includes the subject matter of Examples 1-8, further comprising an API gateway to receive one or more structured data files.

[00152] 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-l producer or a K-l receiver to be registered users in the database.

[00153] 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.

[00154] 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-l producers and one or more K-l receivers.

[00155] 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-l producers, which are financial entities that issue schedule K-l documents and K-l receivers, which are persons to whom schedule K-l 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-l producer and/or a K-l 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-l producers and K-l receivers provides data access to one or more of each other’s structured data files.

[00156] Example 14 includes the subject matter of Example 13, wherein the validating step rejects a data file inconsistent with the universal data schema.

[00157] 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.

[00158] Example 16 includes the subject matter of Examples 13-15, wherein the (i) K- 1 data; and (ii) an K-l exchange certificate are bundled into a single data file.

[00159] Example 17 includes the subject matter of Examples 13-16, wherein the universal data schema further requires one or more attachment files.

[00160] Example 18 includes the subject matter of Examples 13-17, wherein the universal data schema requires structured data files with K-l 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.

[00161] Example 19 includes the subject matter of Examples 13-18, wherein the universal data schema requires structured data files with a K-l 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.

[00162] 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.

[00163] Example 21 includes the subject matter of Examples 13-20, further comprising an API gateway to receive one or more structured data files.

[00164] 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-l producer or a K-l receiver to be registered users in the database. [00165] 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.

[00166] 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-l producers and one or more K-l receivers.

[00167] 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-l producers, which are financial entities that issue schedule K-l documents and K-l receivers, which are persons to whom schedule K-l 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-l producer and/or a K-l 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-l producers and one or more K-l receivers to establish access control therebetween. The access control between connected K-l producers and K-l receivers provides data access to one or more of each other’s structured data files.

[00168] Example 26 includes the subject matter of Example 25, wherein there are instructions to reject a data file inconsistent with the universal data schema.

[00169] 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.

[00170] Example 28 includes the subject matter of Examples 25-27, wherein the (i) K- 1 data; and (ii) an K-l exchange certificate are bundled into a single data file.

[00171] Example 29 includes the subject matter of Examples 25-28, wherein the universal data schema further requires one or more attachment files.

[00172] Example 30 includes the subject matter of Examples 25-29, wherein the universal data schema requires structured data files with K-l 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. [00173] Example 31 includes the subject matter of Examples 25-30, wherein the universal data schema requires structured data files with a K-l 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.

[00174] 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.

[00175] 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.

[00176] 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-l producer or a K-l receiver to be registered users in the database.

[00177] 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.

[00178] 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-l producers and one or more K-l receivers.