Source Documents Should Be Evidence, Not Data-Entry Instructions

A financial statement arrives. The preparer opens it, reads a number, finds the corresponding input in the tax program, types the number, and repeats. The document may eventually become an attachment in a document-management system. The tax software receives the answer, but often very little of the reasoning that made it an answer.

That workflow makes the professional the connection between two systems that ought to share more context. It also makes the most repetitive part of preparation look like the most important part.

The important work is establishing what the return should report. That means understanding the evidence, identifying omissions and contradictions, making tax decisions, and being able to explain the result. Transcription is sometimes necessary. It should not be the organizing principle of the whole product.

PrepReturns starts from a different premise: source documents belong inside the preparation process. They are evidence to review, with their own identity and history. They are not just instructions for filling out a separate input screen.

A document can be authentic and still be wrong

The word “evidence” is deliberate. It does not mean that a document has authority over the return merely because someone uploaded it.

Consider an illustrative payroll reconciliation. A financial statement contains an employee-benefits account. A payroll report separately identifies retirement contributions and other benefits. The totals may agree while the categories do not. Alternatively, one document may cover a different period, omit a payment, or contain an actual bookkeeping error.

Software cannot settle those possibilities simply by choosing whichever file arrived last. Nor should it turn a disagreement into a silent balancing adjustment. The preparer needs to see which amounts disagree, where they came from, and what each source actually purports to establish.

This is familiar professional work. The software improvement is to retain its structure instead of requiring the preparer to reconstruct it from windows, notes, and memory.

Evidence supports a conclusion. It does not eliminate the need to reach one.

There are at least three different values

When people say that an imported number is wrong, they may mean several different things. A useful preparation system needs to separate them.

First is the value in the original source. Second is the value the software read. Third is the fact the preparer established for use in the return. Those values may agree. Agreement does not make them the same concept.

Imagine a source that visibly says $72,000. A parser reads $72,000. The preparer then determines, from additional evidence, that the relevant amount is $68,000. That is a different event from a parser reading $72,000 when the source actually says $68,000.

In the first case, the interpretation of the document was accurate and the document was not the final authority. In the second, the reading was inaccurate. If both operations become “edit amount,” the system loses a useful distinction.

The original document should remain original. Its recorded reading should remain identifiable. The corrected or established fact should have a reason and an appropriate review state. A reviewer should be able to tell whether they are looking at a transcription repair or a professional adjustment.

This is why a clean final number is not enough. The path matters.

Correcting a reading is not correcting the books

This distinction has practical consequences for the interface.

Suppose a parser misses an expense row that is plainly present in a supported financial-statement layout. Adding that missed row can be a source-reading correction: the preparer points to existing evidence the software failed to represent.

Now suppose the expense does not appear in the financial statement at all. The preparer has separate support for it. Calling that an “omitted parser row” would falsely suggest that the original document contained information it never contained. The appropriate path may be a supported workpaper adjustment or a corrected source, depending on the situation and product scope.

Likewise, an extra software reading of one source row differs from two real rows that happen to be duplicates in the underlying books. Removing an extra reading repairs the import. Resolving duplicated bookkeeping requires a different explanation.

PrepReturns’ source work has made these distinctions concrete through bounded correction, addition, exclusion, classification, and replacement workflows. That does not make every source problem automatically resolvable. It establishes a more useful standard: the action should describe what happened, and an unsupported situation should remain visible.

Unknown needs its own place

A missing amount is easy for software to mishandle. Many interfaces make an empty field look like zero. Many calculations are easier to run if the software quietly fills in a default.

Preparation is not improved by making uncertainty disappear cosmetically.

“No retirement contribution was made,” “the amount has not been established,” and “this question does not apply” are different statements. An unavailable payroll report does not establish zero payroll. A prior return’s balance sheet does not, by itself, establish a shareholder’s complete tax-basis history.

These are not merely warnings to display after calculation. They belong in the data model. A known zero should be usable as a zero. An unknown should remain a question. An unsupported treatment should be a boundary. A deferred matter should retain the fact that someone deferred it.

This makes progress more honest. A return can be incomplete for a specific reason without looking broken. The next useful question becomes clearer because the system knows what it does not yet know.

Review should establish something

An “Accept” button is meaningful only if its consequences are clear. Is the preparer confirming that a file belongs to the right entity? That a row was read correctly? That an account classification is appropriate? That the amount is complete for the year? Those are different decisions.

Compressing them into one green checkmark risks making the interface look more certain than the underlying work. A source can be reviewed while a related tax question remains unanswered. A category can be confirmed while a reconciliation remains unresolved.

The objective is not to make preparers click through an endless series of attestations. It is to place decisions where they matter and to avoid asking for the same decision twice without a reason.

When established evidence already answers a question, Guided Preparation should use that context. When the evidence cannot answer it, the software should ask plainly. That is the logic behind the PrepReturns workflow: automation proposes, and the professional establishes what governs.

Corrections have consequences beyond one field

Changing an accepted amount may affect a workpaper, a reconciliation, a calculation, and the return package. It may also undermine a review decision that was reasonable before the change.

For example, correcting an account classification could reopen a payroll/books comparison. Replacing a source might conflict with a later manual edit. A software system that silently reapplies the replacement could erase work the preparer deliberately performed.

Preserving history is therefore only part of the problem. The system also needs dependency awareness: what was accepted because of this fact, and what needs attention now that the fact changed?

There is no universal “latest value wins” rule that makes this safe. A later file may be less authoritative than a reviewed adjustment. A later edit may be accidental. Sometimes the appropriate behavior is to stop and expose the conflict rather than invent a merge.

Good automation takes care of mechanical consequences while leaving contested authority visible. The professional should not have to remember every downstream location, but the software should not resolve a substantive disagreement on their behalf.

Provenance must survive the finished package

The benefit of source review should continue after preparation. A saved return represents a particular set of facts, decisions, and calculations. If those facts change later, the old return does not retroactively become a different return.

That sounds obvious when discussing a paper file. It is less obvious in a live application, where every screen can appear to represent “the case” without identifying which preparation it belongs to.

PrepReturns’ saved-package model distinguishes historical output from current preparation. A later change can make the current package stale, and an updated preparation creates a new package. This gives evidence history an operational purpose: the reviewer can understand which inputs produced the output being reviewed.

It also makes corrections easier to explain. The question becomes “What changed between these preparations?” instead of “Why does this PDF disagree with what the screen says today?”

Better ingestion does not require pretending documents are universal

There is considerable room to improve document ingestion. There is also a temptation to describe every improvement as universal understanding.

The existing PrepReturns workflow uses supported parsers and structured source paths. Its development with frontier AI models is a separate fact. AI-assisted implementation does not establish that the runtime parser uses an LLM, performs OCR, or understands arbitrary documents.

Those distinctions matter because the professional needs to know what sort of review is required. A supported layout with defined fields has different failure modes from a broader extraction system. Neither should have its output promoted into unquestionable truth.

A better evidence architecture makes future ingestion improvements more useful. New extraction methods can propose facts into an existing review and provenance process. They do not need to become a second authority system.

The ambition is broader, easier intake with explicit boundaries. It is not an excuse to obscure how today’s software works.

The purpose is less clerical work and better attention

Evidence-centered preparation is sometimes described as an audit trail feature. That understates it. It changes what the preparer spends time doing.

If information has already been established, the software can carry it forward through the workflow. If two sources disagree, the disagreement can become the task. If a required fact is missing, the question can name the missing fact instead of sending the preparer through an unrelated input tree.

The gain is not a promise that review disappears. It is a better allocation of review. Human attention is scarce and valuable; it should be directed toward uncertainty, treatment, completeness, and the return’s meaning.

That is especially important when a return is conventional but substantial. Multiple owners, payroll, assets, and distributions can create plenty of work without requiring an exotic tax structure. A cleaner evidence path helps organize that work without pretending it is trivial.

Let the document keep its story

The right question is not simply whether software can read a document. It is whether the preparation system can use that reading without losing the distinction between evidence and conclusion.

A useful system preserves the original, identifies the proposal, records the professional’s decision, and carries the established fact into a calculation that can be explained. When the source is incomplete or wrong, it should provide a truthful recovery path within its supported scope.

That is the direction behind PrepReturns’ evidence model. Documents enter the workflow as participants in the reasoning, not as files parked beside it. The preparer remains responsible for the conclusion, with software that helps preserve how the conclusion was reached.

The next step is to follow that history all the way to the form line. Every number needs a story because a finished return should be explainable after the last input screen closes.