What is the Digital K-1?

After looking through our guides and endpoints we have available, you may have encountered the term "Digital K-1" or "K1x Standard". These terms are interchangeable and refer to a JSON object that contains all the Federal K-1 data we store in our system related to a single Investment. The Digital K-1 captures all Federal K-1 data regarding the issuer and the recipient, as well as State K-1 and Schedule K-3 data, depending on the type of investment.

Exploring the JSON

{
  "Version": {},
  "Standard1065": {},
  "Standard1041": {},
  "Standard1120S": {},
  "StateK1Information": {},
  "SupplementalInformation": {},
  "ForeignDisclosures": {}
}

Starting at the highest level, here is the basic structure of the K1x Standard. You'll notice that we store data related to all major K-1 form types, as well as additional information for state K-1s and foreign disclosures. We will walk through all the K-1 form data structures to get a feel for what kind of information we store. You can expect to see every data point available on the PDF for these K-1s reflected in our models. It ultimately comes down to where that information is stored and how to locate it.

Form Data Structures

{
  "Version": {},
  "Standard1065": 
  {
    "PartnershipInfo": {},
    "PartnerInfo": {},
    "PartnersShareInfo": {},
    "IsFinalK1": false,
    "IsAmendedK1": true,
    "IsOCR": false,
    "Summary": {},
    "FormK3": {}
  },
  "Standard1041": {},
  "Standard1120S": {},
  "StateK1Information": {},
  "SupplementalInformation": {},
  "ForeignDisclosures": {}
}

{
  "Version": {},
  "Standard1065": {},
  "Standard1041": 
  {
    "EstateOrTrustInfo": {},
    "BeneficiaryInfo": {},
    "BeneficiaryShareInfo": {}
  },
  "Standard1120S": {},
  "StateK1Information": {},
  "SupplementalInformation": {},
  "ForeignDisclosures": {}
}

{
  "Version": {},
  "Standard1065": {},
  "Standard1041": {},
  "Standard1120S": 
  {
    "CorporationInfo": {},
    "ShareholderInfo": {},
    "ShareholderShareInfo": {}
  },
  "StateK1Information": {},
  "SupplementalInformation": {},
  "ForeignDisclosures": {}
}

{
  "Version": {},
  "Standard1065": 
  {
    "PartnershipInfo": {},
    "PartnerInfo": {},
    "PartnersShareInfo": {},
    "IsFinalK1": false,
    "IsAmendedK1": true,
    "IsOCR": false,
    "Summary": {},
    "FormK3": 
    {
      "PartnershipInfo": {},
      "PartnerInfo": {},
    	"ScheduleK3Parts": {},
      "PartnersShareOfPartnershipsOtherCurrentYearInternationalInfo": {},
      "ForeignTaxCreditLimitation": {},
      "ForeignPartnersDistributiveShareOfDsiOnTpi": {},
      "InformationToCompleteForm8621": {},
      "InformationOnPartnersSection951Inclusions": {},
      "ForeignPartnerCharacterAndSourceOfIncomeAndDeductions": {},
      "Section871mCoveredPartnerships": {},
      "OtherInfoForForm1116Or1118": {},
      "InformationOnPartnersSection250Deduction": {},
      "PartnersInformationForBaseErosionAndAntiAbuseTax": {},
      "PartnersInterestInForeignCorporationIncome": {},
      "DistributionsFromForeignCorporationsToPartnerships": {}
    }
  },
  "Standard1041": {},
  "Standard1120S": {},
  "StateK1Information": {},
  "SupplementalInformation": {},
  "ForeignDisclosures": {}
}

As a general rule, we aim to mimic the structure of the PDF in how we organize data within the K-1 form data structure. Likewise, the naming of properties is designed to be relatable to key labels found on the form. For example, in the case of Form 1065, PartnershipInfo corresponds to Part 1, PartnerInfo corresponds to Part 2, and PartnersShareInfo corresponds to Part 3 of the form. We won't cover every single property within these sections here, however, we've included the high-level structure you can expect to see for all Federal K-1 form types that we support.

An important thing to remember when reviewing the form object is that most numerical fields are represented by objects, which we store additional information alongside the value you'd see on the PDF. We will expand on this in the section where we discuss Lines.

Lines and How We Represent Them

Arguably, the most important data on these forms are the numbers. The type of information we capture for each number largely depends on the context. By in large, we use two primary data structures: A Federal Line and a base Line.

{
  // Line code for lines like 11C, 11D, etc. (e.g., "C" for 11C would appear here)
  "Code": "C",
  "Value": 100.0,
  "UbiValue": 10.0,
  "UbiPercentValue": 10.0,
  "Details": [],
  "StateValues": {},
  "StateUbiValues": {}
}

{
  // Line code for lines like 11C, 11D, etc. (e.g., "C" for 11C would appear here)
  "Code": "C",
  "Value": 100.0,
  "Details": [],
}

One of the first things you'll notice when comparing the two models is that the Federal Line object and the base Line object share a few properties, but the Federal Line contains more information. This is because the Federal Line is used for the main Federal K-1 form objects and includes additional context of how that line value might be split up into UBI and how it might be allocated differently for states.

However, most, if not all, line amounts we capture across all forms will at least appear as a base Line, since we capture the context for how that amount can be separated out into details or events. If there's an opportunity for a line amount to be allocated out to states or if portions are included in UBI, it will be represented as a Federal Line.

Representing State Allocated Amounts for Lines

{
  // Line code for lines like 11C, 11D, etc. (e.g., "C" for 11C would appear here)
  "Code": "C",
  "Value": 100.0,
  "UbiValue": 10.0,
  "UbiPercentValue": 10.0,
  "Details": [],
  "StateValues": 
  {
    "Co": 25.0,
    "In": 20.0,
  },
  "StateUbiValues": {}
}

To represent how a line item amount is allocated to different states, our StateValues property is a dictionary where the keys are state abbreviation codes and the values are the amount allocated to each state.

Line Details

Another important aspect of line information is the Details. Our model supports the ability to add Details for each Line, no matter if it is a Federal or base Line.

{
  // Line code for lines like 11C, 11D, etc. (e.g., "C" for 11C would appear here)
  "Code": "C",
  "Value": 100.0,
  "UbiValue": 10.0,
  "UbiPercentValue": 10.0,
  "Details": 
  [
    {
      "Description": "An important detail!",
      "Value": 60.0,
      "Date": "10-11-2024",
      "Details": []
    },
    {
      "Description": "Another important detail!",
      "Value": 40.0,
      "Date": "10-11-2024",
      "Details": []
    }
  ],
  "StateValues": {},
  "StateUbiValues": {}
}

When it comes to Details, you'll notice that, in addition to the obvious elements like Description and the Value, we also have a nested Details property. Our definition of Details is actually recursive, allowing you to add details to your details!

The idea behind this structure is that you have your top-level Value on the Line object, which should be the sum of all the details. The details then represent individual slices of that larger amount, providing additional context for that top-level value.

How to Get the Digital K-1

Now that we have a working understanding of the structure of our Digital K-1, let's walk through how to retrieve it from our API. Currently, we do not support uploading the Digital K-1 or managing line item data for an investment after it has been created. The only way to get the numbers present in the Digital K-1 output is to go through our upload flow outlined here.

Once you've uploaded your K-1 PDF and received a status of "Processed" from our status endpoint, you can use our Digital K-1 retrieval endpoint with the same GUID you used for the status check, to get the Digital K-1 for the newly created investment.

curl --request GET \
     --url 'https://api-aggregator.k1x.io/api/investment/k1x-standard?uploadId=<UPLOAD GUID>' \
     --header 'accept: application/json'

Parameters