May 2026

Compounding Returns: Learning from the corrections nobody writes down

How Accrual gets better between tax seasons, and what our first full year of returns taught us.

Scott Sutfin-Glowski and Kristen Keats

Every accounting firm has a category of work that never gets written down. A preparer notices an account name is wrong, a foreign dividend allocation is missing, or a value routed to the wrong worksheet. They fix it and move on. There is no ticket, no email, no training session. The fix happens, the return gets filed, and the same mistake is just as likely to happen on the next return.

For an AI tax prep platform, those silent corrections are the most valuable signal in the system. They are also the easiest to lose.

Tax Season 2026 was Accrual's first full season preparing 1040s end-to-end at production scale. Firms ran thousands of returns through the platform. Throughout the season we shipped dozens of improvements in response to issues preparers flagged. That work mattered, but it has a structural limit: it only captured the corrections someone has time to write up.

The moment the April 15 deadline cleared, we set out to capture everything else. Inside each firm's tenant, we ran a structured comparison between every draft Accrual produced and the filed version of the same return. From those patterns, we built the infrastructure to identify fixes, automatically, with verification that runs against real returns inside the firm's own instance. Once you can replay a return with a proposed change and observe the result, tax preparations become testable. A change can be proposed, run against the affected return, checked against similar returns, and reviewed before it reaches production.

We call this body of work Compounding Returns.

What We Compared After April 15

To understand what we did after April 15, it helps to be precise about how a return moves from Accrual draft to filed return.

Accrual produces a draft return, with every field cited back to a source document. From there, a preparer or reviewer makes adjustments. Some of those adjustments happen inside Accrual, where the preparer asks the agent to fix an issue and the change flows through the system. Others happen directly in the tax engine, where the preparer edits worksheets by hand.

The second path is where most of the learning was being lost. There was no feedback loop. A senior preparer would notice that a junior's draft (in this case, Accrual's) had an account named in the wrong convention, or that a foreign dividend allocation was missing because the supplemental brokerage page wasn't being read, or that a 1095-B coverage box needed to be ticked, and they would just fix it in the tax engine and move on. The fix never came back to us.

This is rational behavior. During busy season, reporting every correction to support takes time, and senior preparers are already used to correcting the draft work without writing it up each change. They don't have time to provide written feedback every time. So we automated the feedback process instead. After the season, we run a separate reconciliation for each firm, comparing the filed returns from the tax engine against the original Accrual draft. The comparison shows exactly what changed between what Accrual produced and what the firm filed.

That comparison contains three distinct kinds of corrections:

  • Missing context Accrual could not have had. A clarification discussed with the client on the phone, a 1099-NEC the preparer knew from prior-year context to exclude, a judgment call. The agent should flag these for review, but it cannot resolve them on its own.
  • Firm-specific preferences. A specific account naming convention, a preferred ordering, a stylistic choice. These are not errors in any objective sense, but they are real work the preparer had to do.
  • Genuine Accrual mistakes. The model misread a document, missed a field, or routed a value to the wrong section. These are the gaps we should fix.

The system surfaces the first more clearly for your team's review, lets us encode the second for your firm year over year, and acts on the third directly through the autonomous loop. The goal is to reduce the number of steps it takes to go from an Accrual draft to a firm-finalized return. Closing this loop is the single best tool we have for it.

From those comparisons, we grouped preparer corrections by what the model got wrong, by worksheet, field, and form. The patterns that emerged were not necessarily the issues anyone had time to flag during the season. They were the corrections preparers made outside of Accrual, directly in the tax engine.

What Accrual Learns, and What It Does Not

A natural question, especially for firms evaluating AI systems, is what exactly is being learned, from what, and by whom.

The short version: Accrual improves tax preparation logic. Client data stays firm-scoped. Client data is never used to train models.

Most of what the improvement loop learns is how to interact correctly with the tax engine. Where supplemental 1099 pages need to be read for foreign dividend allocations. How K-1 state allocations should be routed for partnership returns. This is tax preparation logic, not insights derived from any particular client's situation, and the fixes ship to every firm on the platform.

Client return data is firm-scoped, and stays that way. Client data is kept within each firm's Accrual tenant, and no other firm sees it. When a proposed change is identified through review of one return, we verify it by re-running the updated tax preparation logic within the firm's own instance.

No model is trained on your client data. The improvement loop changes the tax preparation logic Accrual follows, not the underlying models. We do not fine-tune models on returns, and our model providers do not train on data sent through Accrual.

The Patterns We Found in Preparer Corrections

The corrections clustered into a handful of recurring patterns. When Accrual reviews a new gap, it first classifies the issue by the type of correction the preparer made:

  1. Duplicate records. A K-1 imported from prior-year data already has the payer name and EIN populated. When the new K-1 arrives, the agent creates a fresh row instead of merging into the existing one. The reviewer ends up with two K-1s for the same partnership.
  2. Missing records. Six 1099-Rs in the binder, but only four appear on the return. The values that did come through are correct, but two records are missing. Or an entire section of a long document, like the supplemental Foreign Income page on a 30-page consolidated 1099, is not read at all.
  3. Wrong merges. Two W-2s from the same employer for two spouses get collapsed into one. The documents are distinct, but the matching logic treats them as duplicates.
  4. Wrong location. Every value is correct, but a local tax landed in "Additional State/Local Tax" instead of "Other Taxes Paid." Or when a W-2 Box 14 amount ends up at the wrong worksheet path. The arithmetic works; the placement is off.
  5. Wrong granularity. On a consolidated 1099, transactions that should have been summarized with code "M" get listed individually, or transactions that should have been listed individually are summarized. The data is there; the level of detail is wrong.

Classifying the issue first matters because different patterns require different fixes. A missing supplemental page is not the same problem as a duplicate K-1 or a value placed on the wrong worksheet.

How Proposed Fixes Move From Gap to Production

Identifying gaps is only half the job. The harder half is fixing them with evidence, without regressing returns that were already correct. We built the tax-fix agent to make that process repeatable, testable, and reviewable.

The process starts with a specific gap: on one return, a field was empty, but should have had a value. From there, the agent runs the full cycle:

Reproduce. Replay the affected return against the current logic and confirm the issue still exists. If it's already been fixed, stop.

Diagnose. Trace the issue through the preparation workflow, from document summarization to planning, worksheet editing, and citation matching. Classify the issue by correction pattern and determine whether it can be addressed through a change in the preparation logic. If it cannot, stop and report. Some gaps require new product capability; the agent does not paper over them.

Patch. Write a tightly scoped patch using the same terminology already in the preparation logic. The agent prefers adding to existing logic over replacing it, which reduces the risk of unintended side effects.

Verify on the affected return. Replay the return with the proposed change. If the output now matches the expected value, advance. Otherwise revise and test again.

Regression sample. Inside the same firm's instance, identify similar returns, based on document types, form counts, filing status, and other relevant attributes, then replay those returns with the proposed change.

Open a change request for CPA review. The change request includes the issue, the proposed change, before-and-after results, regression results, and a detailed description of what changed.

One step is deliberately not automated: approval. Every change request the agent opens is reviewed by an in-house CPA before it merges. Nothing reaches production without that sign-off.

The changes the agent proposes are not code in the traditional sense. They are tax-preparation logic: how to read a supplemental brokerage page, when to treat a 1099-B entry as a summary versus a detail row, and how to allocate K-1 state income. The right reviewer for that work is a CPA, not an engineer. So CPAs review.

The full cycle now runs in hours. Work that used to take a multi-week cycle across firm user feedback, engineering, and our internal CPAs is now a single agent invocation followed by a focused CPA review of a well-documented change request.

What Shipped in the First Week

In the first week after April 15, 17 fixes moved through the CPA-reviewed fix loop and reached production. The remaining items are working through the same loop now.

Real World Examples

Mortgage interest double-export when limited. When a client's mortgage exceeded the applicable $750K principal limit, Accrual was exporting the interest to both the Sch A Mortgage Interest section and the Limited Home Mortgage Interest Deduction worksheet. The tax engine then summed both, overstating the deduction.

The Sch A logic and the limited-mortgage worksheet were each correct in isolation, but the interaction between them was wrong. The right value appeared in two places, counting it twice. The proposed change sets the "Mortgage Interest" override correctly when the limited mortgage worksheet is populated, so the tax engine sums only one source. Regression testing on returns where the mortgage was not limited showed no impact.

Foreign dividend allocation on consolidated 1099s. A consolidated 1099 from a major brokerage runs more than 30 pages, and the foreign dividend breakdown that a return needs for Form 1116 may appear several pages past the 1099-DIV summary, in a supplemental "Foreign Income" or "Foreign Tax Paid by Country" section. Accrual was reading the 1099-DIV totals correctly but stopped there. The supplemental page never made it into the worksheet.

The proposed change added an explicit step in the consolidated 1099 logic: locate the supplemental page and populate the foreign sub-allocations, including total ordinary dividend, qualified dividends, country code, and income category. On a sample of consolidated 1099 returns where foreign data was present in the source, the updated output matched the preparer's filed values to within rounding. Returns without foreign income in the source were unchanged.

What This Changes for TS27

The practical implications for the next tax season are straightforward.

Every reviewed return creates a firm-scoped feedback signal Accrual can use to improve future drafts without training models on client data. Genuine Accrual gaps move through the CPA-reviewed fix loop. Judgment calls and missing context get surfaced more clearly for your team's review. Firm-specific preferences, including account-naming conventions, preferred ordering, and presentation choices, can be encoded year over year. The same mechanical correction should not have to be made return after return.

The improvement loop is faster and more controlled. Identifying a gap, proposing a fix, proving the fix works on the affected return, and checking it does not regress similar returns used to be a laborious human task. It is now a single agent invocation that opens a draft change request with full evidence attached. Engineering time is spent on the architecture and on the gaps the agent flags as non-patchable, the genuine new capabilities the system does not yet support.

The system is correctable in a directed way, not a guess-and-check way. When a firm flags an issue, we can replay their exact return inside their tenant, with the same documents, against any proposed change. We can say, with specifics: here is the patch, here is what happened on your return, here is what happened on the next dozen similar returns at your firm. That conversation is qualitatively different from "we'll look into it."

The work that took thousands of corrections to surface in TS26 is being addressed now, months before extension season and TS27 begin. Each improvement removes one more step between an Accrual draft and a firm-finalized return. If you ran returns through Accrual this season, expect to be surprised next.

Accrual is an AI-powered tax preparation platform built for enterprise accounting firms. To learn more, reach out to our team or contact us.