A founder can have every document their accountant requested and still lack a usable tax file. The folder may contain a wage statement (Form W-2), two Schedule K-1 forms, a brokerage statement, a digital-asset broker statement (Form 1099-DA), wallet exports, an ownership spreadsheet, and a foreign subsidiary ledger. Each file is readable on its own. The difficulty is that the same person, entity, asset, date, and dollar amount appears in several files, often with different labels or incomplete history.
Software for complex tax situations should connect those records, map facts to draft forms, show the evidence behind each important number, and stop when a human decision is required. It should attach each draft number to its source, calculation inputs, unresolved questions, and approval state rather than make an uncertain answer sound finished.
In this series, Tangle Tax Agent means a proposed workflow from Tangle, the project behind this series, for that preparation job. It is an AI tax agent in the ordinary sense: software that can organize documents, extract candidate facts, run bounded calculations, and prepare questions for a reviewer. This article does not claim that a public Tangle product is an IRS-authorized preparer or that it can resolve every tax position without a taxpayer or qualified professional.
This is not tax advice. Founder returns can require tax, legal, and accounting review.
Why founder returns become a connected problem
An entity is a separate company, partnership, trust, or other structure that can own assets, earn income, or issue tax documents. A founder’s personal return can depend on several entities at once.
An S corporation is a corporation that has made a federal tax election allowing certain income, losses, deductions, and credits to pass through to shareholders. Form 1120-S is the federal income tax return for that corporation. Its Schedule K-1 is the schedule that reports one shareholder’s share of the corporation’s items.
A partnership K-1 serves a similar reporting purpose for a partnership, though the underlying rules differ. The IRS’s current Form 1120-S instructions say the shareholder’s K-1 reports the shareholder’s separate share and can include information needed for state and local returns. The current partner instructions for Schedule K-1 (Form 1065) explain how partnership items, activity information, and limitations are carried into the partner’s return.
The software needs to link shared entities, owners, dates, amounts, and assets across source documents and downstream form fields.
| Record | Fact it can support | Downstream question |
|---|---|---|
| W-2 | wages and withholding from an employer | Do the employer, tax year, and states match the payroll record? |
| Form 1120-S and shareholder Schedule K-1 | S corporation income, deductions, credits, and distributions | Does the shareholder’s basis support the loss or distribution treatment? |
| Partnership K-1 and attached statements | Pass-through income, deductions, credits, and state or international details | Are the activity, basis, passive, and state items mapped separately? |
| Equity plan and brokerage statement | Option, restricted stock, sale, proceeds, and basis candidates | Which event created income, and which later event created a sale? |
| Foreign company records | ownership, officer or director status, financials, and foreign taxes | Does the fact pattern need Form 5471 or another international review? |
| Exchange and wallet records | digital asset acquisitions, transfers, rewards, and dispositions | Can the software match ownership and reconstruct basis? |
| Estimated payment confirmations | amounts, dates, and jurisdictions paid | Do federal and state payment records reconcile? |
The table is a dependency map, not a promise that any one document answers the question beside it. For example, a K-1 can report a loss without proving that the shareholder may deduct the full loss. An exchange statement can report proceeds without containing all the basis history needed to calculate the result. Foreign-company ownership can raise a reporting question even when the company made no cash distribution.
A founder scenario exposes the hidden joins
Consider Elena, a software founder with the following illustrative file set for one tax year. The numbers below are made up to show the workflow, not to calculate Elena’s tax.
| File | Candidate fact | What the software must not assume |
|---|---|---|
| W-2 from Elena’s company | wages and federal withholding | that payroll covers all compensation or all state obligations |
| Form 1120-S K-1 | ordinary business income and a non-dividend distribution | that the K-1 amount is automatically deductible or that the distribution is automatically tax-free |
| Partnership K-1 | income plus a state footnote | that federal and state amounts can share one line |
| Broker statement | stock sale proceeds and a reported basis | that the broker’s basis includes every earlier transfer or compensation adjustment |
| Wallet exports | several transfers, a swap, and staking rewards | that every outgoing transaction is a sale or every incoming token has the same tax treatment |
| Foreign subsidiary cap table | Elena owned shares and served as a director for part of the year | that no distribution means no information-return question |
| Estimated-payment receipts | payments made to two states and the federal government | that a bank transaction with a similar amount is the correct payment |
The first output should be an inventory of those files and the questions they create, rather than a filled Form 1040.
Suppose Elena’s S corporation K-1 reports a loss, while the basis workpaper from the prior year is missing. The agent can extract the loss and mark the basis input as unavailable. It should not convert the missing workpaper into a zero basis, because zero is a fact and “not provided” is a status.
Suppose one wallet export shows an asset leaving Wallet A and another shows the same quantity arriving in Wallet B six minutes later. The agent can propose a transfer match when the asset, quantity, owner, and timestamps support it. It should preserve the match as a candidate until the taxpayer confirms that both wallets belong to the same owner.
Suppose the foreign subsidiary ledger is in euros and the cap table is in percentages, while an earlier note says Elena sold part of her interest in June. The system needs an ownership timeline and a currency record before it can flag which forms or schedules warrant review.
The common failure is a complete-looking return assembled from disconnected extractions. Each cross-document match should retain its evidence, confidence state, and reviewer decision.
Build the fact record before drafting forms
A source index is a list of every document, statement, upload, and taxpayer answer that entered the work session. For each source, the index should retain the tax year, owner, document type, page count, import status, and source location.
A source-to-line mapping connects a draft return line or schedule item back to the document, transaction, calculation input, or approved answer that supports it. This mapping is the difference between “the system says $42,000” and “the system used page 3 of the brokerage statement, minus the documented adjustment, and a reviewer accepted the result.”
The following TypeScript is an illustrative data shape for that distinction. It is application code for a review workflow, not a private Tangle implementation and not a tax calculator.
type ReviewState = 'candidate' | 'accepted' | 'needs-review' | 'blocked'
type SourceRef = {
documentId: string
page?: number
location?: string
excerpt: string
}
type CandidateFact = {
key: string
value: string | number | null
unit?: 'usd' | 'percent' | 'shares' | 'tokens'
source: SourceRef | null
state: ReviewState
question?: string
}
const basisFact: CandidateFact = {
key: 's-corporation-beginning-stock-basis',
value: null,
unit: 'usd',
source: null,
state: 'blocked',
question: 'Provide the prior-year basis workpaper or confirm that it is unavailable.',
}The important choice is the explicit null and blocked state.
An extraction model can suggest a value, but the application should not pass a missing input into a downstream calculation as though it were confirmed.
Each fact also needs a unit. A sample value such as “20” can mean 20 dollars, 20 percent, 20 shares, or 20 tokens. The source excerpt gives a reviewer enough context to catch a bad normalization before the fact changes a form.
The source hierarchy should be visible rather than absolute. An official IRS instruction can explain what a form asks for. A signed entity document can support ownership. A bookkeeping export can support a transaction total. A taxpayer answer can resolve who owns a wallet or why two documents differ. None of those sources automatically outranks every other source for every question. The system should show the conflict and state which source a reviewer accepted.
Route work by consequence
A review route is a workflow state that determines who must answer a question and what remains blocked. It is not a tax conclusion.
| Route | Example | Required next step |
|---|---|---|
| Accepted | W-2 wages match the employer statement and withholding record | Carry the fact into the draft and retain the source link |
| Taxpayer question | The system cannot identify whether two wallets have the same owner | Confirm ownership or add a source document |
| Advisor review | Foreign ownership, an uncertain entity classification, or a large basis gap | Send the facts, sources, and question to a qualified reviewer |
| Blocked | A required K-1 or prior-year workpaper is missing | Keep the draft incomplete and name the missing input |
| Superseded | A corrected K-1 replaces the earlier statement | Preserve both versions and recalculate affected outputs |
This routing lets software move quickly through low-consequence extraction while slowing down where a wrong assumption can change a filing position. It also gives the founder a reason for the delay. “Foreign ownership timeline incomplete” is actionable. “AI confidence low” is not enough for a high-stakes review decision.
The review packet is the product boundary
A review packet is the set of records a taxpayer or advisor needs to inspect a draft before approval. For Elena, it should contain the following pieces.
| Packet section | What it should answer |
|---|---|
| Source index | Which files arrived, which opened, and which expected files are missing? |
| Fact register | What did the system extract, from where, with what units and review state? |
| Reconciliation log | Which records disagreed, and how was each conflict resolved? |
| Basis workpapers | Which beginning balances, contributions, distributions, and sales inputs support the draft? |
| Foreign review | Which ownership dates, financial records, currencies, and forms need specialist attention? |
| Digital asset review | Which wallets were included, which transfers matched, and which lots remain unresolved? |
| Draft forms | What forms and schedules were prepared, and which remain unapproved? |
| Change log | What changed after a correction, a late document, or a reviewer decision? |
| Approval record | Who approved which version, and which issues were accepted or escalated? |
The following is an illustrative API shape for a review packet. It is not a public Tangle endpoint.
POST /review-packets
Content-Type: application/json
{
"taxYear": 2025,
"returnType": "founder",
"requireApproval": true,
"sources": ["w2.pdf", "s-corp-k1.pdf", "wallet-export.csv"]
}This is where Tangle Tax Agent should be concrete. The proposed workflow should let the agent create those artifacts in one work session, retain the sources beside them, and leave filing behind an explicit approval step. The product claim is reviewable preparation, not automatic correctness.
The same pattern connects this post to AI Tax Preparation For Complex Returns, which explains source-linked workpapers, and Automated Tax Filing With Review Before Submit, which explains why submission needs a separate approval state.
If a future implementation exposes this workflow through a public API, its service description should expose the input documents, draft artifacts, and approval boundary without hiding the underlying tax uncertainty. A system record does not prove a tax position. The evidence belongs in the workpapers a reviewer can open.
The safe stopping points are specific
There are several legitimate stop conditions.
The agent should stop when an expected K-1 is missing, when an amended K-1 changes an earlier entry, or when an attached statement contains information the main form does not capture. The current IRS instructions for partnership K-1s explain that partners may need to account for activity, prior-year limitations, and attached information separately.
It should stop when the prior-year basis record is unavailable and a current loss or distribution depends on that history. The IRS’s S corporation stock and debt basis guidance explains that stock and debt basis affect loss and distribution treatment.
It should stop when a foreign company’s ownership, financial statements, or functional currency is unclear. The current Form 5471 instructions contain multiple filer categories, schedules, and year-specific rules that cannot be inferred from the phrase “foreign subsidiary.”
It should stop when a digital asset sale has proceeds but no defensible acquisition history. The IRS treats digital assets as property and expects taxpayers to report taxable transactions even when a statement does not provide every basis input. The current digital asset guidance and Form 8949 instructions are better anchors than a model’s generic explanation.
A stop should preserve progress. The founder should be able to export the source index, the open questions, and the draft workpapers for an advisor instead of starting from an empty inbox.
A practical test for software selection
Ask the vendor or internal team to demonstrate one fictional founder return with a missing basis workpaper, a late K-1, a matched wallet transfer, and an ownership change. The test is more revealing than a clean upload demo.
| Ask the system to show | A useful result | A failure |
|---|---|---|
| Remove a prior-year basis file | The affected loss or distribution is marked blocked | A new basis value appears with no source |
| Add an amended K-1 | Changed lines and dependent state questions are listed | The replacement silently overwrites the first K-1 |
| Match two wallet entries | The proposed match names the owner, asset, quantity, and evidence | The outgoing asset disappears from review without a match record |
| Change foreign ownership midyear | The timeline and affected filing questions update | A single year-end percentage is used everywhere |
| Ask for the final number | The system returns a review packet with unresolved items | The system returns a confident total with no evidence |
This test measures whether the software preserves reasoning under incomplete inputs. It does not measure whether a model can recite tax terminology.
A review packet still needs a tax decision
Source links show where a value came from; they do not prove that a document is authentic. An extracted value can be wrong even when the page reference is correct. A matched wallet transfer can be wrong if the taxpayer owns one address through a separate entity. A complete review packet can still contain an incorrect tax position.
The workflow also does not eliminate state filing analysis, legal entity work, or professional judgment. State allocation, foreign reporting, equity compensation, and digital asset treatment can depend on facts outside the files the founder first uploads.
Show the unresolved fact, affected form or schedule, supporting sources, and required reviewer action.
Choose the packet, not the promise
Choose software for a complex founder return only when it can connect entities and assets, retain source-to-line evidence, version late corrections, and pause before unresolved facts become filing inputs. For a simple return with one employer and complete records, a lower-friction filing product may be the better choice. For a founder return with multiple entities, foreign ownership, equity, crypto, or missing history, the review packet is the feature that matters. For the multiple-entity reconciliation inside that packet, continue with K-1 tax filing software.
What does complex tax situations software do?
It organizes records from employers, entities, brokers, wallets, and tax authorities, then maps supported facts into draft forms and review questions. It should preserve the evidence and uncertainty behind important outputs.
Why are founder tax returns difficult?
They often combine personal income with company ownership, S corporation or partnership K-1s, equity transactions, digital assets, foreign reporting, estimated payments, and multiple states. The difficulty comes from reconciling those facts across records.
Can an AI tax agent file a founder return without review?
The workflow described here should prepare a draft and require explicit taxpayer or advisor approval before filing. It should stop when ownership, basis, foreign reporting, state allocation, or source completeness is uncertain.
What should I request before trusting the result?
Request the source index, source-to-line mapping, basis workpapers, reconciliation log, open questions, draft forms, and approval record. If the product cannot show those artifacts, treat its answer as an explanation rather than a finished return.