The K-1 Factory

Last year we filed returns for 10,616 venture funds and issued 353,859 K-1s. Priced at market rates for partnership tax services, the software we've built delivered roughly $71.4 million of tax services in 2025.

We did that with three engineers and no dedicated product manager.

What follows is how.

What "filing taxes for a venture fund" actually involves

Before we get to the interesting engineering, we need a shared vocabulary for what "filing taxes for a venture fund" actually involves.

A venture fund is a legal entity — usually a Delaware Limited Partnership (LP) — that pools capital from investors (the limited partners, or LPs) and deploys it through a manager (the general partner, or GP). Under U.S. tax law, the fund is a partnership. A partnership does not owe federal income tax; instead, income, deductions, and credits flow through to the partners, and each partner reports their share on their own return. That pass-through design is what makes venture funds economical — no corporate-level tax skimming compounding returns before they reach the investor.

Every year, on or before March 15, the fund has to file its own return, produce a personalized tax document for every investor, and clear a stack of other obligations that vary by activity:

That's the happy path. The unhappy path adds state nexus determinations, foreign portfolio company classifications (CFC/PFIC rules), cost basis reconciliations, QSBS eligibility tracking, and dozens of other calculations that live in the corners of Subchapter K of the Internal Revenue Code.

For any single fund, this is one accountant's full-time job for a few weeks — and the going rate for it at a traditional accounting firm runs upwards of $50,000 per fund per year. For 10,000+ funds, "add more accountants" is not the answer.

From judgment calls to dependency graphs

Look closer at that pile of obligations and a structure emerges. You close the fund's books and produce financial statements. You translate book numbers into tax numbers — GAAP and tax accounting disagree in specific, nuanced ways, and every disagreement is its own calculation. You allocate the results across every partner, weighted by how their capital moved during the year. Then each partner's own attributes — home state, foreign status, tax exemption — fan out into their own filings. Every step depends on the ones before it. The work is not a checklist; it is a dependency graph. And to file, you need to know that every node in it is either resolved or explicitly parked.

So how do you know when a fund is ready? The industry's answer is an experienced partner who looks at the fund and makes a judgment call — and venture-partnership CPAs are the scarcest resource in the industry. Our answer is different.

Every fund that enters our tax pipeline gets decomposed, automatically, into a comprehensive graph of discrete tasks. Every calculation the fund needs. Every external request it depends on. Every review step. Every release blocker.

Once that graph exists, tax pros no longer manage individual K-1s and individual returns — they manage the graph. When every task in it is either resolved or explicitly waived, we know the fund is ready to ship. And not just that fund: we know it for every fund, all ten thousand of them, at once. When a fund isn't ready, the graph tells you exactly what is outstanding, what is blocking it, and — via each task's category — whether it needs a specialist, a workflow, or nothing at all.

If you've built CI/CD systems, the analogy is immediate. You don't ship a release because someone looks over the repo and decides it feels ready. You ship when the tests are green, the security scans pass, and the deploy gate is unblocked. Release windows, deploy queues, rollback plans — everything downstream becomes mechanical because readiness is defined by a computable expression over the state of the checks.

We do the same thing for tax returns.

The graph also answers when. A fund that is unblocked from day one ships by the March filing deadline. A fund that is blocked — waiting on audited financial statements to close, or on K-1s from upstream partnerships to arrive — releases as soon as the last node in its graph resolves. Nobody assigns a fund its timeline; the graph does.

Every task in the graph belongs to a category of work, and every category sits at one of three levels of automation — from a human working a queue, to no task existing at all.

Three levels of automation, walked through one fund

To make the levels concrete, take a single fund that recently went through our pipeline. We'll call it Imperial Ventures. Three tasks in its graph, three different degrees of automation. We'll start with the most automated one and work our way down.

Level 3: fully automated

Imperial Ventures made a cash distribution to its LPs during the year. Under the K-1's Section L reporting, each partner's 19A field (the distribution of cash line) needs to reflect their share of what was paid out.

There is no task for this in Imperial Ventures' graph. There never was.

The distribution was ingested automatically from our accounting system. The amount was allocated across the fund's partners according to their ownership percentages and the fund's LPA. Each partner's capital account was updated. Each partner's 19A field was populated on their K-1. Nobody assigned the work. Nobody reviewed the work. Nobody knew the work happened, in the same way nobody at your bank knows any specific ACH transfer happened.

This is the target state for every category of tax work in the long run. A structured signal arrives from a system that already owns the source data, the business logic runs, the output lands in the right field on the right K-1, and there is no task at all — because there is nothing left to coordinate.

Not every category is there yet. The next two tasks in Imperial Ventures' graph show what the intermediate states look like.

Level 2: workflow-enhanced

Next in the fund's graph, as one example category among many: Digital Asset Compliance Request.

If a fund had any crypto activity — a token distribution, an airdrop, a wallet transfer — that activity has specific tax consequences, and we need the fund's GP to certify what did or didn't happen. Unlike a cash distribution, we can't source this from an upstream ledger; the fact lives outside the system and has to come from a human.

Without a workflow, the surrounding work is enormous. A tax pro has to identify which funds are affected. Look up each GP's contact info. Compose a personalized email. Send it. Remember to follow up. Log the response somewhere. Then translate the response back into the fund's tax position.

We built a Flowdash workflow for this category. Flowdash is our internal workflow builder — it handles any human-in-the-loop step in the pipeline. The system automatically identifies affected funds, emails each GP a standardized form with structured fields, receives the response as structured data, attaches it to the fund's record, and unblocks the task in the graph. The tax pro never has to send an email or wait for a reply.

The judgment is still human — the GP is still asserting a fact about their own wallet activity — but every unit of coordination overhead around that judgment goes to zero. And once the coordination is structured, the category is a step away from level 3: as soon as the same fact can be sourced from an upstream system, the task disappears entirely.

Digital Asset Compliance is one example of many. Every category of work that touches an external human (GPs, LPs, portfolio companies, state authorities) is a candidate for the same lift. But some categories don't have a workflow yet. Those live one step further down.

Level 1: the work queue

Finally, the system flagged Imperial Ventures with a task labeled Potential Final Year Fund Not Marked Final. When a fund has no active assets left at year-end, that year's return is usually its last — what we call a final year filing. The IRS treats final returns differently, so it matters that we identify them correctly.

But usually is not always. Sometimes additional proceeds from a portfolio company's merger, acquisition, or wind-down arrive late and still have to be distributed out to the LPs.

There is no specialized workflow for this category of decision yet. The task flows into our catch-all work queue in Flowdash. A tax pro picks it up, looks at the fund's actual position, decides whether to mark the return final, and closes it. Because work arrives as categorized tasks rather than whole funds, tax pros specialize by concept — and several of them can move the same fund forward in parallel. The graph updates. The fund moves forward.

This is what level 1 looks like: the coordination is systematized — the task was surfaced, prioritized, assigned, and tracked — but the judgment is still human, and the coordination around that judgment hasn't been built out into its own workflow yet. In 2025 the queue moved 53,479 tasks — 26% more than the year before — with no meaningful headcount growth.

Most tax platforms don't even have level 1. For us, it's the product roadmap — every category still in the queue is a candidate to become a workflow, and eventually to disappear.

Why the system compounds

Imperial Ventures sees all three levels on the same set of K-1s. So do the other 10,000+ funds we file for. But the reason the system compounds — rather than just scales — is that the layers stack. Each type of structured data we've invested in sits one step downstream of the last: structured transactions are what allocations are computed from; structured allocations are what state and foreign filings fan out of; and once every remaining piece of work is a task with structured state, release orchestration itself becomes automatable. Every investment makes the next one cheaper.

At a traditional firm, every row of that table is a hiring plan. State returns are filed essentially by hand, one jurisdiction at a time, so the labor cost scales with the number of state-partner combinations; RGL volume growth translates directly into headcount. Here, the growth landed on categories we had already built around, and the team stayed the same size.

We count these investments deliberately: 33 major platform bets since tax year 2019, every one of which either moved a category of work down a level — base to workflow, or workflow to automated — or added a new type of structured data that unlocked the next category.

Here is the punchline of that compounding. In all of 2023, we shipped tax returns for 8,012 funds. In Q1 of 2025, we shipped 8,031 — more than three-quarters of the year's 10,616 funds. The rest weren't late: they were funds whose graphs were still waiting on external dependencies — audited financials, upstream K-1s — and released on their own schedules later in the year, exactly as designed. One quarter of one year now beats everything the system could produce two years earlier.

What this feels like as an engineer here

The tax team at AngelList has three engineers.

There is no dedicated product manager. Every engineer owns their features end to end — writing the spec, talking to the tax pros, designing the data model, writing the code, shipping the deploy, and watching what happens the first time a real fund runs through the change during a release window.

That end-to-end ownership is the reason the compounding actually works. When you write a spec, you already know the requirements, because you spent last release cycle sitting next to the tax pro who resolved four hundred of them by hand. When you design the data model, you already know which downstream automations will need it, because you're the one who's going to build those automations next quarter. When something breaks in production, you already know how the tax pro who caught it will describe the problem, because you have their Slack open.

That closeness to the domain is the part of the job that is hardest to communicate in a job description and easiest to feel from inside the team. You are not building a platform for a persona you have never met. You are building infrastructure that specific colleagues will use starting Monday morning. When you eliminate a category of manual work, you can name the person whose calendar just opened up.

You will also learn a surprising amount of tax law. Nobody expects a new engineer to walk in fluent in Subchapter K, but by the end of your first year you will know enough about partnership allocations, book-to-tax adjustments, state nexus, and foreign withholding to hold real design conversations with CPAs. I built the first version of this system as an engineer who had never filed a Form 1065 — the core data models came from reading Subchapter K alongside two partnership tax accountants and turning what they knew into structures an engineer could build. The domain expertise gets absorbed as a consequence of shipping features, not as a prerequisite for starting. Every engineer we've hired since has had the same experience.

We've also incorporated our domain expertise into agentic tooling to accelerate the product roadmap. Specifically, we've spent the past two quarters building and using what we call the Tax Agent Harness — a set of internal tools and workflows for using Claude and other agents on everything from writing production code, to drafting product specs, to investigating on-call issues, to generating one-off backfill scripts. That's a separate blog post. What matters here is that the team is small enough for a new tool to change how everyone works within a week of trying it.

We are a long way from done. There are categories of tax work still living in level 1 that we fully intend to move down. There are types of structured data we do not yet have that would unlock the next generation of automation. There are hundreds of millions of dollars of external partnership tax work still running today the way ours used to run five years ago.

If any of that sounds like the kind of problem you want to work on, our team is hiring. You do not need a tax background. You need to be interested in getting close to a domain and finding the software-shaped edge in it.

Explore open engineering roles at AngelList.