Frontier challenges in AI tax prep: K-1 processing

Every tax season, the same bottleneck appears: Schedule K-1s. They arrive late, they arrive in non-standard formats, and they carry state-specific nuances that even experienced preparers have to look up. K-1 processing (including K-3s) has become a focal point for AI-powered tax automation for good reason. But as we've learned building Accrual, extracting data from a K-1 is only half the problem.

But the industry's framing of the problem is too narrow. Most tools treat K-1 processing as an extraction challenge: scan the document, pull the numbers, hand them to a preparer. Extraction alone is not the hard part anymore. The harder problem is comprehension: given everything in this K-1 packet, the taxpayer's state residency, the entity's elections, and how this K-1 was handled last year, which fields in the return should these numbers populate, and why?

That's how we've built Accrual's agent. Not as an extraction layer that reads documents, but as a preparation system that comprehends them in the context of the full return and the client's interactions with the firm. In this post for CPAs and firm leaders, we walk through the challenges that make K-1 preparation genuinely hard, the failure modes we've encountered and fixed in production, and what firms should look for when evaluating tools.

Extraction vs. preparation

The difference between K-1 extraction and K-1 preparation matters.

Extraction tools solve a real problem. They turn a PDF into structured data: federal amounts, state amounts, footnotes, K-3 data. For firms processing hundreds or thousands of K-1s, that alone eliminates enormous manual effort. But extraction answers the question "what does this K-1 say?" It doesn't answer the harder question: given everything this K-1 says, what fields in the tax return should I populate, and with what values?

That second question is where the complexity lives.

Consider a straightforward example: a Pennsylvania non-resident K-1 from an S corporation. The K-1 reports $84,278 in ordinary business income sourced to PA, plus $2,980 in PA state withholding. An extraction tool can read those numbers perfectly. A preparation system needs to know what to do with them:

• PA-sourced income for a non-resident doesn't go in the individual income line items on the federal K-1 worksheet. It goes in the State Amounts grid, in the "State use - code" and "State use - amount" fields.
• The withholding goes in a separate field in that same grid.
• The state use code varies by state, with no universal enumeration.

Get this wrong, and the income is "in the system" but in the wrong place. The return calculates incorrectly. Worse, it creates a false sense of completeness during review, because the numbers are there. They're just flowing to the wrong state calculation. This is why extraction alone can still leave firms with review risk.

The three-layer problem

Reliable K-1 preparation requires reasoning across three distinct layers: Document understanding, Planning, and Worksheet population.

Most existing tools collapse these three layers into one: extracting a fixed set of fields from the document. That works for straightforward federal K-1s. It breaks down the moment you encounter a non-resident state K-1 with a PTET election, withholding, and state-specific modifications. That combination isn't an edge case. Across our client base this season, over half of all K-1s included state supplements, one in three involved PTET elections, and clients with 10+ K-1s routinely spanned five or more states with different routing rules for each.

Document understanding. Reading the K-1 packet, which often includes not just the federal K-1 but state-specific supplements, PTET election notices, footnotes explaining special allocations, and sometimes free-form attachments from the partnership's accountant. The system needs to extract all of this and understand how the pieces relate.

Planning. Before any fields are populated, the system determines the overall strategy for this K-1. Is this a resident or non-resident state? Did the entity make a PTET election? Are there state additions or subtractions that modify the federal amounts? Should a separate state worksheet be created, or do the amounts belong in the federal K-1 worksheet's State Amounts grid? These decisions must be made holistically, not field by field.

Context is what separates extraction from preparation

This is also where context beyond the document itself becomes essential. The prior-year return provides the SALY (same-as-last-year) baseline: how activities were classified, which elections were made, how state amounts were routed. Client responses can change that strategy entirely. A change in residency or a disposed partnership interest can alter where amounts belong in the return. A standalone extraction process, no matter how accurate, lacks important context to make that decision reliably.

Worksheet population. Actually placing values into the correct fields in the tax software. This is where state-specific routing rules create the most opportunities for error. The tax software's field structure matters: in CCH Axcess, for example, the 1065 K-1 worksheet and the 1120S K-1 worksheet use different field names for the same conceptual data, and the State Amounts grid has fields whose meaning changes depending on context.

The PTET problem: 36 states, 36 sets of rules

If non-resident state K-1 routing is the first frontier challenge, Pass-Through Entity Tax is the second, and it's growing more complex every year.

PTET emerged as a workaround to the federal $10,000 SALT deduction cap. The basic structure: instead of individual partners or shareholders deducting state taxes on their personal returns (subject to the cap), the pass-through entity itself elects to pay state tax at the entity level, generating a deduction that bypasses the SALT cap entirely. Partners then receive a credit or income exclusion on their individual returns.

The problem for AI systems is that PTET implementation varies across jurisdictions in ways that matter for return preparation. As of 2026, over 36 states have enacted some form of PTET, and the rules differ on nearly every dimension that affects how a return is prepared. The variations fall into a few patterns:

Different calculation methods for the same tax. Maryland recently introduced a split calculation for S corporations: resident members are taxed on their full federal distributive share, while non-resident members are taxed only on state-sourced income. The same K-1 from the same entity routes to different fields depending on where the taxpayer lives.

Penalty and credit modifications that change year to year. California has extended its PTET through 2030 but added a 12.5% credit reduction penalty for late or underpaid entity-level elections starting in 2026. The agent needs to know not just that a PTET election exists, but whether the election was timely and fully funded.

Timing rules that decouple the election from the K-1. Michigan now allows elections up to nine months after year-end, so a K-1 received in March might reflect a PTET election that wasn't made until September. The document alone doesn't tell you whether PTET applies. The agent has to reason about timing.

Sunsets and expirations. Minnesota's PTET expired entirely after 2025. A system that handled Minnesota PTET correctly last year needs to know to stop handling it this year.

For a preparation system, this means the agent can't just read the K-1. It needs to understand the PTET context for each state, recognize when an election has been made, and route amounts to entirely different fields than it would for a standard K-1. A PTET credit on a New York K-1 flows to a different place than ordinary income from the same entity.

What this looks like when it goes wrong

To make this concrete, here are two planning failures we previously observed. In both cases, the document was read correctly. The failure was in how the return was prepared.

Income in the wrong fields. A partnership K-1 (1065) with PA-sourced income was processed by the agent. It correctly identified the income amount but placed it in the individual line items on the federal K-1 worksheet rather than in the State use fields. The numbers appeared on the return and flowed to the wrong state calculation. A reviewer scanning the federal K-1 input would see the income and assume it was handled correctly.

Income missed entirely. An S corporation K-1 (1120S) with the same PA-sourced income was processed, and the agent captured the state withholding but completely omitted the state-sourced income. The withholding showed up with no corresponding income. This is a red flag during review, but only if the reviewer knows to check the State Amounts grid against the source K-1.

Both failures stemmed from the same root cause: the planning layer lacked the routing rules to distinguish non-resident state income from resident income. The document was read correctly. The extraction was accurate. But without explicit logic for how non-resident sourced income routes to a fundamentally different set of fields, the agent defaulted to the resident path.

This is the kind of error that extraction alone will not catch. The numbers are present and look correct at a glance. It only becomes visible when you compare the K-1 source against the worksheet destination and understand the routing logic that connects them. Each new state, entity type, and election combination introduces another branch in that logic. Building it correctly requires all three layers working together: document understanding to read the full packet, planning to determine the right routing given the taxpayer's context, and worksheet population to place values in the exact fields the tax engine expects.

Questions worth asking when evaluating tools

If you're a firm leader evaluating AI tax preparation tools for K-1 processing or broader return preparation, these frontier challenges should inform your diligence.

Does the tool handle state K-1 supplements, or only federal K-1 data? If it only extracts federal amounts, you're still doing manual work for every multi-state K-1.

How does the tool handle PTET? With 36+ states now operating PTET regimes and the rules changing annually, the tool needs to keep pace with legislative changes, not just document formats.

Does the tool use context beyond the document itself? A K-1 processed in isolation will often route correctly for simple cases and incorrectly for complex ones. The system should incorporate the prior-year return, client responses, and entity-level elections when determining where amounts belong. If it can't, the planning layer is missing.

Does the tool differentiate between extraction and preparation? Knowing the numbers is necessary but not sufficient. The tool needs to understand the destination: where in the return each amount belongs, given the full context of the taxpayer's state residency, the entity's elections, and the tax software's field structure.

Can the tool explain its reasoning? When a K-1 is processed, can you see why the agent routed income to the State use fields instead of the individual line items? Auditability is a requirement for K-1 processing, because the routing logic is where errors hide.

Where this is headed

K-1 processing is where Accrual started, and it remains one of the hardest problems in AI tax preparation. The document formats are inconsistent, the routing rules are state-specific and change annually, and the consequences of errors are silent. They don't throw exceptions. They produce wrong returns.

We're continuing to expand state K-1 coverage, build deeper PTET intelligence, and refine the planning layer that sits between document extraction and worksheet population. Every edge case we encounter in production makes the system more reliable for the next firm that processes that same type of K-1.

If you're evaluating AI tax prep for complex K-1 workflows and want to see how Accrual handles the cases that break other tools, reach out to our team or contact us.

This post is part of Accrual's CPA Series, where we explore the technical accounting challenges behind AI-powered tax preparation.