The partner and shareholder income statement, read as an extraction problem

This is a United States document, and everything below is specific to it. Schedule K-1 is the statement a pass-through entity issues to each owner reporting that owner's share of the entity's income, deductions, credits and other items for the tax year. Partnerships issue it with Form 1065; S corporations and estates or trusts issue their own versions on different forms, with different layouts and different box meanings, so the form variant is part of the record and not a detail.

As an extraction target it looks deceptively easy: a fixed grid of numbered boxes, printed the same way every year, with the amounts in obvious places. Take only the grid and you get a row of numbers a preparer cannot use, because the number in a box is meaningless until you also have the letter beside it and the statement it points to.

Three parts, and only one of them holds the money

The form is divided into 3 parts. The first identifies the entity that issued it. The second identifies the recipient and carries the facts that decide how the amounts may be used — ownership percentages at the start and end of the year, share of liabilities, and the capital account analysis. The third is the distributive share: the numbered boxes people mean when they say K-1 data.

Part II matters more than its position suggests: percentages that change mid-year, a moving capital account and a share of liabilities are inputs to limitations applied later. Capture Part III alone and the preparer gets amounts with no way to test whether they are usable.

A box number without its code letter is not an amount

Several boxes in the distributive-share part are containers rather than single values. Other income, other deductions, credits and other information each hold a list, and every line in that list carries a code letter that says what the amount is. Codes run through the alphabet and continue into 2-letter pairs, which is the tell that the designers expected the list to grow.

The consequence for a schema is blunt. A table with 1 numeric column per box cannot represent the document: a single box may carry 6 coded lines, and the same box on the next K-1 none. The storable unit is the triple of box, code and amount, with the tax year attached, because a code letter that meant one thing 2 years ago may mean another now.

The box tells you where the number was printed. The code tells you what it is. Only one of those is worth storing on its own, and it is not the box.

Sign convention deserves the same care. A negative amount on a coded line is part of the item's meaning rather than a formatting choice, and normalising signs on the way into a ledger-shaped table destroys information — the same modelling error as treating a credit note as a negative invoice.

The amounts that only exist in the attached statements

The printed form is a summary that frequently defers to pages behind it. The instructions are explicit about one case: where the partnership had more than 1 activity, it attaches a statement identifying each activity and specifying the income, deductions and credits from each. Activity detail, apportionment data, basis and at-risk information and disposition detail all commonly arrive this way.

Those pages are the hard part. They are free-form, produced by whichever software the entity's accountant used, unnumbered relative to the form, and often laid out as tables breaking across pages. So the record needs a statement reference on the item — a pointer from the coded line to the block explaining it — or the preparer gets an amount and a stack of unlinked pages and redoes the reading you automated.

The packaging makes this worse. Form, statements and state schedules usually arrive as 1 scanned or emailed bundle, so the boundary detection step decides whether the footnotes stay attached to the K-1 they belong to. Split the bundle wrongly and the amounts survive while their explanations are filed elsewhere, which is the failure examined in a batch scan that splits into the wrong documents.

One partner, nine states, nine versions of the same figure

An owner in a multi-state entity receives state-level detail as well as the federal form, typically as supplementary schedules whose content and format are set by each state rather than by any single standard. The same conceptual item can appear once federally and again, differently, for each jurisdiction. Which states are involved is itself the output of a nexus determination made by the entity, a data problem in its own right, taken apart in nexus thresholds as a data problem.

So jurisdiction is a field on every item, not a separate document type. A federal amount and a state amount for the same box and code are 2 rows differing by 1 column; modelling them as unrelated documents guarantees they get reconciled by hand.

The addressable unit: box, code, amount, jurisdiction, statement

Two of those fields carry more weight than they look. Status is the one that prevents double counting: an amended statement replaces the original, and a pipeline that appends produces a partner with twice the income they had. Citation is the one that makes review possible at all, for the reasons set out in showing a reviewer which page a figure came from.

The document cannot check itself

A bank statement proves its own completeness: opening balance plus movements must equal the closing balance, which is why a mis-parse is caught before a human sees it, as in the extracted statement that does not foot. A K-1 offers nothing equivalent. Boxes do not sum to a control total, and a missing coded line looks exactly like a line the entity had no reason to report.

So the checks have to come from outside the page: capture the count of coded lines per box, compare against the statements attached, and flag a coded line with no matching statement where the instructions require one. Nothing here is tax advice — code meanings, state requirements and the treatment of any amount are matters for the preparer signing the return. All of it belongs to extraction and classification of source documents; the tax-season document systems we build for accounting and tax practices are scoped under internal tools and ops.

• tax documents
• extraction
• pass-through entities
• data model