Firms ask this late, usually after they have already decided the rest is fine. It is the right question and it deserves a direct answer, so here is the direct answer first.
Today you get a structured worksheet and you key from it. Not a file that imports straight into Drake, UltraTax, Lacerte or CCH. A vendor adapter that would do that is work we have designed for and have not built.
We would rather say that plainly than let a firm discover it in week two of a pilot. What follows is what you do get, why it is worth considerably more than the PDF most desks send, and what has to be true underneath for a direct import to ever be trustworthy.
The thing underneath is not a spreadsheet
The worksheet is a rendering. What sits behind it is a single normalised structure built from two sources at once: the organizer the taxpayer completed, and the figures extracted from the source documents. Both are compiled into one 1040-anchored payload.
That matters because the alternative — which is what most outsourced work actually is — is a preparer reading documents and typing numbers into a spreadsheet by hand. When that spreadsheet reaches you, the chain from a figure back to the page it came from exists only in that preparer’s memory.
The worksheet is generated from the payload rather than typed. That is the whole difference, and everything below follows from it.
Every figure carries where it came from
In the payload, no number is a bare number. Every value — every amount, every string, every yes or no — travels with its own provenance.
We did that for three reasons, and only one of them is about you.
The first is that preparers do not trust an extracted figure they cannot trace, and they are right not to. A review screen that shows a number without showing where it came from is asking for agreement it has not earned.
The second is that section 7216 and a two-enrolled-agent review process both need an audit trail of who accepted which figure. Not that a figure was accepted — who accepted it.
The third is the one that will matter if a direct import ever lands. A disputed import has to be replayable against the inputs that produced it. If the only record of how a number got into your tax software is that our system put it there, you have bought a black box with better manners.
Nothing is silently dropped
The rule the builder is written to is that every field from an organizer has exactly one of three outcomes. It is anchored to a line, it is on the unmapped list with a written reason, or it is on an explicit ignore list. There is no fourth outcome.
This is enforced rather than aspired to. The payload builder never fails on input it does not recognise, because one unrecognised organizer key must not be able to block an entire case. The unrecognised thing goes to the unmapped list and the case keeps moving.
A field you can see on an unmapped list with a reason attached is a field you can argue with. A field that vanished is one nobody will ever raise.
The same discipline runs through the document side. The mapping from extracted figures to 1040 line buckets lives in one declarative table, read by both the payload builder and the year-over-year variance screen. They cannot drift apart and report two different numbers for the same set of documents, because they are reading the same table.
Corrections sit beside the evidence, never on top of it
When a preparer disagrees with a figure — an extraction misread a box, or the taxpayer answered an organizer question loosely — the correction does not overwrite anything.
The taxpayer’s original answer survives. The extracted figure survives. The override is recorded beside them as a third opinion, and all three remain visible.
If you have ever tried to reconstruct why a return said one thing when the source document said another, you already know why this is built that way. The reconstruction is usually impossible, and it is usually needed at the worst moment.
Two things that deliberately do not block
Before a payload can be approved, certain things must be resolved: conflicts between sources, failed extractions, and any document that maps to no bucket at all. Those are real blockers.
Two things that might sound like they should block do not, and both decisions are worth explaining because they are the kind a vendor usually hides.
Unmapped fields do not block approval. On a fully completed organizer there are routinely dozens of them, most entirely harmless. Forcing a preparer to acknowledge dozens of items trains them to click through everything in front of them, which is strictly worse than not asking. The list stays visible; it just does not gate.
Extraction confidence is not a gate either. The field exists in the data structure and nothing populates it. We could have wired a confidence threshold into the approval flow and described it in a sales deck. A control that reads as real while gating on a value that is always empty is worse than no control, because it buys trust it has not earned.
That second one is the honest version of a feature we could easily have claimed. It is also the standard we would want applied to anyone else’s pipeline, which is the point of the questions we suggest asking any prep desk.
What is in the sheet, and what is deliberately not
The worksheet carries the income lines, the document list with what each one contributed, and the needs-attention items.
It does not carry the identity blocks — taxpayer, spouse and dependents, which is where Social Security numbers live. It is generated on demand and never stored, so there is no archive of client financial detail sitting in a bucket waiting to be misconfigured. It is firm-side only.
None of that is a limitation we are apologising for. A file that is never persisted cannot leak from a place nobody remembered it was kept.
Why the adapter is a renderer, not a rewrite
The worksheet is built from the payload structure rather than from the database. That sounds like an implementation detail and it is actually the commitment.
It means a vendor adapter — the thing that would eventually write into Drake or CCH — is a second renderer over the identical input, not a second route through the data. Two renderers over one payload cannot disagree about what the return says. Two independent pipelines eventually will, and the disagreement will surface on a filed return rather than in a test.
So the honest position on direct import is this. It is not built, we are not going to imply it is, and the reason the delay is tolerable is that the hard part was never the file format. The hard part is having something underneath that is worth importing, with every figure traceable to the document it came from.
What to ask anyone else
If you are evaluating another desk this month, the useful questions are not about integrations.
Ask what the deliverable actually is, and whether it was generated or typed. Ask whether you can trace any figure on it back to the page it came from without emailing someone. Ask what happens to a field their system does not recognise. Ask whether a preparer’s correction overwrites the original or sits beside it.
A desk that answers those four well and has no import file is in better shape than one that has an import file and cannot answer them. The import is the last mile. Everything that makes it safe happens before it.
Our desk prepares expat and domestic returns — Forms 2555, 1116, 8621, FinCEN Form 114 and Form 8938, alongside 1040, 1120-S and 1065 work. Every return is prepared by one IRS-licensed enrolled agent and reviewed by a second before it reaches your firm. Your letterhead, your client, your review — our hours. Preparing US returns since 2003 — 5,300+ tax returns filed in the last 4 seasons.