At 9:42 p.m., Maya has a Form W-2, the employer wage and withholding statement, two brokerage statements, a partnership Schedule K-1, the pass-through tax statement, three wallet exports, and a spreadsheet of estimated payments spread across six folders. She asks an AI assistant to “get the return ready,” but the assistant cannot know whether a missing cost-basis record, the acquisition evidence used to measure gain or loss, means zero basis, an unopened attachment, or a transaction that never happened.
AI tax preparation for complex returns is useful when it turns that uncertainty into a reviewable work package. The package should show which documents arrived, which facts were extracted, which records disagree, which calculations ran, and what still needs a taxpayer or advisor decision.
A fluent tax explanation serves a different purpose. This article describes preparation software, not tax advice, and a taxpayer or qualified tax professional must approve the filing position.
Complexity comes from connected facts
Complexity comes from records that have different owners, dates, currencies, entities, or reporting obligations.
Maya’s documents look separate at first, but the facts connect:
| Record | Fact it can support | Fact it cannot settle by itself |
|---|---|---|
| Form W-2 (wage and withholding statement) | wages and withholding reported by an employer | whether a separate business payment was wages |
| Brokerage statement | proceeds, dates, and a broker’s basis field | whether an earlier transfer supplied the correct lot |
| Schedule K-1 (pass-through tax statement) | pass-through items reported by an entity | whether a conflicting ownership agreement is still controlling |
| Wallet export | transactions associated with an address | whether two addresses belong to the same person |
| Entity agreement | ownership, rights, and dates | how every entity fact maps to a tax form |
| Estimated-payment record | payments and dates | whether the payment belongs to the right tax year |
The preparation system should keep those boundaries visible. An extracted value is a candidate fact until a source and a reviewer give it a status.
The Internal Revenue Service (IRS) makes the same evidence problem visible in its public guidance. Its digital-asset guidance says taxpayers should keep records of purchases, receipts, sales, exchanges, and other dispositions, along with fair market value and basis information. Its page for Form 8949, the federal sales-and-dispositions form, describes it as a reconciliation step whose subtotals flow to Schedule D. Software should preserve the records that make that reconciliation possible instead of presenting only the final number.
The first deliverable is a source index
The first screen should show the intake inventory: what arrived? For every upload, record the document name, tax year, owner, page count, file type, processing status, and whether extraction succeeded.
The source index should also distinguish a missing document from a document that was present but unreadable. Those conditions lead to different next actions.
| Intake state | Example | Correct next action |
|---|---|---|
| received | 2025 brokerage statement, 18 pages | extract and attach page references |
| unreadable | scanned K-1 with clipped totals | request a clearer copy |
| duplicate | the same statement uploaded twice | keep one canonical copy and record the duplicate |
| unexpected year | 2024 statement in a 2025 folder | ask whether it is a carryover or an error |
| missing | expected foreign financial statement absent | block dependent work and show the missing fact |
The index is also a privacy boundary. A reviewer should know which files the agent could read and which files never entered the workspace.
Extraction and interpretation need different states
Document extraction can find a number on a page. Interpretation decides what the number represents, which period it belongs to, and whether it can enter a calculation. Those are different operations and should not share one status called “processed.”
Consider this sample brokerage statement that contains the text “basis: 12,000.” The preparation system should preserve the text, normalize the amount, and ask whether the statement covers the same asset lot as the reported sale.
| Sample stage | Example result | Allowed next action |
|---|---|---|
| sample extraction | basis: 12,000 on page 7 | attach the page and retain the original text |
| sample normalization | 12000 USD for the stated tax year | record currency and period assumptions |
| sample reconciliation | acquisition record says 9000 USD | show both values and open a question |
| sample preparation | reviewer accepts the $9,000 record | pass the accepted value to the calculation |
An extraction model can be useful at the first stage and still be wrong about the lot, currency, or tax treatment. The workflow should therefore let a reviewer accept the number while rejecting its interpretation, or request a better source before either value reaches a draft form. This separation also makes failure recovery concrete: an unreadable page needs a new upload, while a conflicting ownership percentage needs a decision.
Facts need a status, a source, and a history
Document extraction turns pages into structured candidates. It does not make every sentence true.
A practical fact record has four parts:
- The value in its original form and a normalized form used by calculations.
- A source reference with the document, page, and excerpt.
- A status such as
candidate,needs-review,accepted, orrejected. - A history of corrections so a later reviewer can see what changed.
This small TypeScript model shows the boundary. It is illustrative application code, not a tax calculation and not a private Tangle interface.
type FactStatus = 'candidate' | 'needs-review' | 'accepted' | 'rejected'
type SourceRef = {
document: string
page?: number
excerpt: string
}
type ReviewFact = {
key: string
originalValue: string
normalizedValue: string | number
source?: SourceRef
status: FactStatus
changedBy?: string
}
const ownership: ReviewFact = {
key: 'partnership-ownership',
originalValue: 'Maya Stone: twenty percent interest',
normalizedValue: 0.2,
source: {
document: 'partnership-agreement.pdf',
page: 4,
excerpt: 'Maya Stone: twenty percent interest',
},
status: 'needs-review',
}
console.log(ownership)The source is optional in the type because the missing-source case must be representable. The application should prevent an unreferenced, high-impact fact from entering a draft form without an explicit review decision.
Reconcile before you calculate
Reconciliation means comparing records and showing where they disagree. It is the point at which the workflow stops pretending that the first extracted value is the right one.
Maya’s agreement says she owns 20% of a partnership. The K-1 says 15%. The agent should preserve both facts, show both pages, and ask which document governs the return.
| Field | Agreement | K-1 | Preparation state |
|---|---|---|---|
| ownership percentage | 20% on page 4 | 15% on page 2 | needs-review |
| document date | March 3, 2025 | January 31, 2026 | compare effective dates |
| calculation impact | changes pass-through allocation | changes pass-through allocation | block dependent draft |
The same pattern catches duplicated brokerage sales, a wallet transfer that appears as a withdrawal and a deposit, and a foreign-currency amount whose conversion date is unclear. The agent should not silently choose the newest file, the largest number, or the value that makes the refund look better.
A conflict record can be simple. It can be serialized as JSON (JavaScript Object Notation) when it crosses a service boundary:
const conflict = {
field: 'partnership-ownership',
values: [
{ value: 0.2, document: 'partnership-agreement.pdf', page: 4 },
{ value: 0.15, document: 'k1-statement.pdf', page: 2 },
],
status: 'needs-review',
}
console.log(JSON.stringify(conflict, null, 2))The useful output is the unresolved question beside the conflict. “Which ownership percentage applies for the 2025 return?” is actionable. A bare confidence score gives the reviewer no decision to make.
A worked calculation should stop at the missing fact
Once accepted facts are structured, deterministic code can calculate narrow values. The model should not be asked to infer a tax liability from a paragraph.
Maya’s sample preparation packet contains $180,000 of wages, $2,400 of interest, and $25,000 of digital-asset proceeds.
The acquisition records needed to establish basis are missing.
In the example code, ordinaryIncomeCandidates is a preparation label for amounts routed to ordinary-income review, not a completed tax classification.
| Sample input | Value | Preparation result |
|---|---|---|
| wages | $180,000 | accepted source-backed input |
| interest | $2,400 | accepted source-backed input |
| reported proceeds | $25,000 | candidate capital-asset transaction |
| reported basis | unavailable | block gain or loss calculation |
The calculator can add the first two income candidates and preserve the proceeds.
It should return null for the gain candidate and create a basis review item.
That is a safer result than filling the blank with zero.
type CalculationInput = {
wages: number
interest: number
proceeds: number
basis: number | null
}
function summarize(input: CalculationInput) {
const gainCandidate = input.basis === null
? null
: input.proceeds - input.basis
return {
ordinaryIncomeCandidates: input.wages + input.interest,
gainCandidate,
needsBasisReview: input.basis === null,
}
}
const result = summarize({
wages: 180_000,
interest: 2_400,
proceeds: 25_000,
basis: null,
})
console.assert(result.ordinaryIncomeCandidates === 182_400)
console.assert(result.gainCandidate === null)
console.assert(result.needsBasisReview)This example does not calculate tax due. The IRS digital-asset guidance says records may need the asset type, transaction date and time, units, fair market value, and basis, so the application should request the missing acquisition evidence before it creates a Form 8949 entry for a sale or exchange. If a broker supplies Form 1099-DA, a digital-asset proceeds statement, the software should preserve that statement while still showing which basis fields are covered and which remain unresolved.
Coordinate the workflow with Tangle and run it in a Sandbox
Tangle coordinates reusable service packages and the operators that run them. Its Sandbox product provides an isolated runtime for agent jobs. The tax workflow described here treats a Tangle Tax Agent as a proposed application built on public Tangle surfaces, not as a claim that Tangle currently provides tax advice or files returns.
These terms describe the boundary:
| Term | Plain-language meaning | Use in tax preparation |
|---|---|---|
| Blueprint | A reusable service definition that lists its jobs, inputs, outputs, and runtime requirements | define a prepare-return job and its review-package output |
| Service instance | One live deployment of that Blueprint | isolate Maya’s preparation session from another taxpayer’s |
| Operator | A party that supplies compute and runs the service instance | run the tax workflow under the required storage and access policy |
| Runtime | The environment where files, processes, model calls, and tools execute | hold uploads, run parsers, and retain generated workpapers |
| Agent profile | A configuration of model, tools, budget, and policies | pin which model can extract facts and which tools can write drafts |
| Router | A component that selects an operator or provider route for a model request | choose an approved model route without changing tax rules |
| Trace | A record of inputs, tool calls, outputs, decisions, and failures in one run | let a reviewer reconstruct how a fact reached a draft line |
| Evaluation | A structured test of task results, cost, and policy compliance | test missing-basis and conflicting-ownership cases before release |
| Attestation | A signed report about measured code and a hardware-backed execution environment | support a confidentiality claim when the deployment uses a trusted execution environment (TEE) |
| x402 | An HTTP payment flow where a server returns 402 Payment Required and the caller retries with payment proof | charge a machine for a preparation job without turning payment into a correctness claim |
The public Tangle Blueprint documentation describes Blueprints, services, jobs, and operators. The Tangle core concepts define agent profiles and evaluations. The Router documentation describes model and operator routing. The x402 documentation describes the payment challenge and retry flow. For the execution boundary, see AI Agent Sandbox, and for the submission boundary, see Automated Tax Filing With Review Before Submit.
Those mechanisms coordinate execution and payment; the tax product still settles the tax position. A Router can select a model route, but it cannot make a missing basis value true. Attestation can bind code to a hardware boundary, but it cannot show that the model’s tax interpretation is correct. An evaluation can catch a regression, but it cannot replace taxpayer approval.
The Tangle Sandbox quickstart documents the scoped package and health endpoint for a runtime smoke test:
npm install @tangle-network/sandbox
curl -fsS https://sandbox.tangle.tools/healthThat check confirms a reachable runtime surface. It does not prove that a tax parser, model, form renderer, or approval flow works.
Rules belong in versioned code and sources
A model can identify that a document mentions a foreign corporation or a passive foreign investment company. It should not decide that a form applies from a keyword alone.
The rule layer should record the tax year, jurisdiction, form revision, rule identifier, inputs, and output. The review packet should link to the official source that explains the relevant form.
For example, the IRS Form 5471 page says certain citizens and residents of the United States who are officers, directors, or shareholders in certain foreign corporations file the form and related schedules. The IRS Form 8621 page lists several conditions involving passive foreign investment company holdings. Those pages establish why a question belongs in review. They do not determine Maya’s filing obligation without the rest of her facts.
Tax-year versioning matters because forms and instructions change. An agent that uses an old rule while displaying a current-looking draft can create a more dangerous failure than an obvious error.
Failure cases need visible stops
The agent should stop or downgrade the output when:
| Failure | Safe behavior |
|---|---|
| a source file is unreadable | keep the file in the index and request a replacement |
| two high-impact facts conflict | preserve both values and block dependent calculations |
| basis is missing | show an exception instead of assuming zero |
| a tax-year rule is unavailable | mark the draft unsupported for review |
| a tool times out halfway through extraction | retain partial results with a failed-step record |
| a private document is sent to an unapproved endpoint | fail closed and record the policy violation |
| a reviewer changes an accepted fact | create a new draft version and recalculate affected outputs |
| a draft is requested for a foreign form | show the facts and questions that still need professional review |
The right failure text is specific. “The 2025 acquisition record for 0.8 units of a digital asset is missing, so the capital-gain calculation is blocked” gives Maya a next action. “The AI is uncertain” does not.
What the review packet should contain
By the end of preparation, Maya should receive a packet with:
- a source index showing every file received, unreadable file, duplicate, and missing document;
- a fact ledger with original values, normalized values, citations, statuses, and correction history;
- calculations with units, inputs, tax year, rule identifiers, and affected draft lines;
- a reconciliation report for conflicts, duplicates, and unmatched transfers;
- a missing-fact list that explains what each requested document would resolve;
- draft forms and schedules marked
unapproved; - an approval record that is separate from the agent’s generated explanation.
An advisor should be able to open the packet and ask “why is this number here?” without rerunning the entire agent. That is the practical meaning of source-backed preparation.
Choose preparation software by its stopping behavior
Use AI tax preparation for complex returns when the system can show the source, assumption, calculation input, and review state behind every high-impact output. Keep a simpler filing path for a return whose facts are clean and whose supported forms already fit a conventional workflow.
If the product gives a polished answer but cannot show the document page, rule version, unresolved question, or correction history, it belongs in the assistant category. Keep it out of the preparation path until it exposes those records for a taxpayer or advisor to review. For the filing-stage boundary, continue with AI tax filing software for complex returns.
What is AI tax preparation?
AI tax preparation is software that organizes tax records, extracts candidate facts, performs controlled calculations, drafts forms or workpapers, and presents unresolved questions for review.
Can AI prepare a complex tax return?
It can prepare a draft package, but complex returns still require taxpayer review and often professional review for foreign reporting, entity ownership, digital-asset basis, and uncertain tax positions.
What should AI tax preparation show before filing?
It should show the source index, source-to-line mapping, calculation inputs, missing facts, conflicts, draft forms, rule versions, and approval state.
Is a confident AI answer evidence that the return is ready?
No. Readiness requires source-backed facts, reproducible calculations, resolved or escalated exceptions, and an explicit approval step.