K-1 aggregator: one that asks instead of guessing, and how to tell

What is a K-1 aggregator? It is software that does K-1 aggregation for an investor: it collects every Schedule K-1 and K-3 the investor is owed from GP portals, email and fund administrators' file drops, tracks which are still missing, and extracts each into data the investor's tax team and tax software can use. Limited partners, funds of funds, family offices and endowments use aggregators because a portfolio of private funds produces hundreds or thousands of K-1s a season, each with its own login, layout and footnotes. The question that separates aggregators is not how many fields they fill but what they do when they are unsure. A UBTI percentage with an ambiguous base, a footnote that changes an item's character, a K-3 built on assumptions about the partner: an aggregator that guesses produces confident errors; one that stops and asks produces questions a person can answer. Botminds' K-1 Aggregation is built on the second design, with seven agents that cite every value and wait for a person below set confidence levels.

Product examples on this page are fictional sample data in the solution. Research and regulatory sources are linked where they appear.

What is a K-1 aggregator? Collection, tracking and extraction in one place

A K-1 aggregator does three jobs that investor tax teams have traditionally done by hand. It collects: it signs in to GP portals, watches a K-1 mailbox and checks administrators' file drops, and matches each document to the holding it belongs to. It tracks: it knows, from the investor's holdings, which K-1s are expected, which have arrived as estimates or finals, and which are missing. And it extracts: it reads every box, code and statement into structured data.

The third job is where aggregators differ most and where buyers should look hardest. Extraction from a clean box is close to typing; extraction from a footnote is closer to interpretation, and what research on manual data entry found shows how much more often interpretation goes wrong. An aggregator that treats both the same way will be most confident exactly where it should be least.

What is a K-1 aggregator used for, and by whom?

Any investor that receives more K-1s than a person can track in a spreadsheet uses one, and the threshold arrives quickly. A fund of funds receives a K-1 from every fund it holds and issues its own to every partner, on the same September 15 deadline when both sides extend. A family office receives K-1s for many entities and trusts, each with a different filing date. An endowment or pension needs the UBTI detail from every K-1 to file Form 990-T. A wealth platform's clients each hold a few funds, but there are thousands of clients.

In each case the aggregator's output is the same: a roster of every expected K-1 per investor entity, extracted values the tax team can trust or check, and evidence of where each value came from. Aggregators sit on the receiving side; a fund's own K-1 preparation is a different job, covered in the K-1 preparation software guide.

How does K-1 aggregation software work? Seven agents, and the people who decide

Every aggregator runs some version of the same chain, from a document arriving to a value in the tax software. The design question is where people sit in that chain. In K-1 Aggregation, seven agents do the mechanical work, and people own every decision that changes a return or a relationship.

Can software read K-1 footnotes? Yes, and that is where it should be least sure

Software can read footnote text and propose a mapping to a box and code, and on routine statements it does so reliably. The difficulty is the footnote that is routine in form and ambiguous in substance. The sample K-1 from Tamsin Bay Real Estate Partners V, a fictional fund, says about 37.2% of net rental income "before depreciation" is debt-financed. Applied to Box 2 that gives UBTI of $106,541; applied to income before depreciation, $153,599. The text is perfectly legible. What it means is a question for the GP.

General-purpose language models are not yet reliable enough to settle such questions alone. In FinanceBench, a 2023 benchmark of 10,231 questions on public company filings (Islam and others, arXiv working paper, not peer reviewed), a leading model of the time used with retrieval answered incorrectly or declined to answer 81% of a 150-question sample (arXiv 2311.11944). Models have improved since, and K-1 footnotes are shorter than annual reports, but the lesson for a buyer holds: ask how a tool behaves when it does not know.

84% sure is not sure enough: the agent puts both readings to a person

What happens when an extraction is uncertain? Two thresholds, two kinds of stop

A well-designed aggregator separates two kinds of uncertainty and treats them differently. The first is reading: is this digit a 3 or an 8, is this amount in Box 13 or Box 14? The second is meaning: which line does this percentage apply to, does this footnote change the character of an item? In the sample settings, values read below 95% confidence are highlighted for the analyst but flow on, while footnote mappings below 90% stop and wait for a person's decision. New UBTI, new K-3 items and changes of character are flagged whatever the confidence.

The K-3 row is not hypothetical caution. The IRS warns partners that what a partnership reports on Schedule K-3 can rest on incorrect assumptions about them, and that the partner must then follow its own actual facts (Partner's Instructions for Schedule K-3, 2025). An aggregator that copies a K-3 without flagging what is new hands that problem to the investor's return.

Measure how often it asks, not only how often it is right

A tool that asks about everything is useless, and one that never asks is dangerous; the useful measure is accuracy on what it answers, alongside the share it hands to a person. Machine learning research calls this selective classification, a trade-off between risk and coverage. One paper on the method, by Geifman and El-Yaniv, describes a method that "allows a user to set a desired risk level," with the classifier rejecting instances "as needed, to grant the desired risk" (Geifman and El-Yaniv, arXiv 1705.08500, published at NeurIPS 2017).

"These techniques can potentially significantly improve DNNs prediction performance by trading-off coverage."

Geifman and El-Yaniv, 'Selective Classification for Deep Neural Networks' (2017)

For a K-1 aggregator, that means two numbers per field type on a sample of your own K-1s: the error rate among values the tool filled without asking, and the share of values it sent to a person. Ask a vendor for both, and for how the confidence thresholds that set the trade-off are chosen, versioned and approved. In K-1 Aggregation they are settings that the administrator proposes and the tax manager approves, and every value carries the agent version that produced it.

What the people keep

Automation in tax work moves effort from keying to judging, and the controls should follow. In K-1 Aggregation, the analyst answers the agents' questions and accepts finals with reason codes; the tax manager approves every export and cannot approve one she prepared; operations approves every message to a GP; and internal audit reads every action, by people and agents, on one hash-chained trail.

Regulators describe their own use of these tools the same way. In its fiscal 2027 priorities, the SEC's Division of Examinations observes firms putting "super intelligence (SI)", its term, to work on drafting and compliance monitoring, and describes its own SI-supported tools as an aid to examiners' analysis that leaves the judgment with its staff (SEC Division of Examinations, Fiscal Year 2027 Examination Priorities). The same division checks that firms using these tools keep meeting the duties they had before, which no choice of tool changes.

K-1 aggregator login: portals, credentials and who can see what

An aggregator is only as complete as its access. Most fund K-1s arrive behind GP investor portals, each with its own login, terms and multi-factor settings, and a portal that stops accepting a login in August is a K-1 that goes missing in September. The sample investor's season ran through 312 portals; on the morning shown, 303 were signing in and 9 needed new credentials, each sent to operations the same day.

Three questions settle most of the security conversation. Where are portal credentials kept, and who can use them: in K-1 Aggregation, in a vault, used only by the Collector agent, which never accepts new portal terms or changes multi-factor settings itself. Who can see which investor's K-1s: analysts act only on their assigned investor entities, and a wealth client's entities are visible only to its controller and named staff. And where the data lives: each investor entity has its own data region. Ask every vendor the same three questions, and ask to see the answers on screen.

Questions to ask a K-1 aggregator before you buy

Vendors' demonstrations use clean K-1s. Your season will not. The questions below are designed to surface how a tool behaves on the documents that cause most of the work.

Where K-1 Aggregation fits in an investor tax team, and its limits

K-1 Aggregation fits investors that receive K-1s at volume and need to know, on any day, what is expected, what has arrived, what it says and who decided what about it: limited partners, funds of funds, family offices, endowments and wealth platforms. It works with the systems already there, GP portals, the K-1 mailbox, administrators' file drops, investment accounting read-only and the tax software, rather than replacing them.

It does not prepare a fund's own K-1s from its books; that is a partnership-side job. It does not make GPs faster, though it makes late K-1s visible early and chases them back from each investor's deadline. And it does not remove judgment: ambiguous footnotes still need a person or the GP. The fair test is your own last season; how to run a pilot on last season's K-1s sets out the pass-or-fail criteria, and the K-1 Aggregation page shows the workflow end to end.

Questions people ask

What is K-1 aggregation?

K-1 aggregation is collecting every Schedule K-1 and K-3 an investor receives from the partnerships it holds, tracking which are still missing, and extracting them into tax-ready data. It is the receiving-side counterpart to K-1 preparation, which a partnership does to produce its partners' K-1s.

What is a K-1 aggregator used for?

For gathering K-1s from many GP portals and other channels in one place, tracking missing ones against each investor's deadline, extracting values for tax software, and keeping evidence of where each value came from. Funds of funds, family offices, endowments and wealth platforms use them because their K-1s number in the hundreds or thousands.

Does a K-1 aggregator replace tax software?

No. It prepares the K-1 data that tax software imports. In K-1 Aggregation the Export agent builds the import with activity numbers and runs twelve checks, and the tax manager approves each export before anything is sent.

Can a K-1 aggregator log in to GP portals for us?

An aggregator can reach a portal only with credentials the investor provides. In K-1 Aggregation the Collector agent uses credentials kept in a vault, never accepts new portal terms or changes multi-factor settings, and asks operations to renew credentials when a portal refuses sign-in.

What happens when the aggregator is unsure?

In a well-designed aggregator, uncertain values are marked rather than filled. In K-1 Aggregation's sample settings, values read below 95% confidence are highlighted for the analyst, and footnote mappings below 90% wait for a person's decision, with both readings and the footnote shown.