Your Client Uploaded Everything. So Why Isn't It Ready?

The email says the client uploaded everything. Your portal agrees. Every file is sitting in the right folder, attached to the right job, named more or less correctly.

And the return is not one step closer to being done.

Because somebody now has to open each file, work out what it is, decide whether it is the current year, and type the numbers into your tax software. That somebody is usually not an administrator. It is a preparer you pay properly, doing work you could describe to a temp, in the six weeks of the year when their time is worth the most.

That is the gap this article is about. Client documents not ready to prep is not a collection problem. Your collection works. It is a translation problem, and almost nothing in your current stack is trying to solve it.

Here is what matters most:

• Karbon collects and files documents well. Karbon itself does not read them. Its document page describes storing, sharing and organising, and nothing else.
• On Karbon's own integrations page, the job of getting client documents into a tax return is advertised as another company's product.
• Karbon lists no integration with Lacerte, UltraTax CS, Drake, ProSystem fx or ProSeries. CCH Axcess is marked coming soon.
• The one real tax engine on that list, Intuit ProConnect, connects at the contact and work level. It carries statuses back into Karbon. It does not push a client's numbers into a return.
• So unless you prep in ProConnect, the bridge between the folder and the return is a person, and that person is usually your most expensive available option.

What the gap actually costs you

Count the steps between a complete upload and a return that can be reviewed.

Somebody opens the folder. Reads each document to identify it. Checks the year, because clients routinely send last year's statement. Notices the brokerage statement is a consolidated one covering four accounts. Opens the tax software. Types. Cross-checks the typed figure against the document. Finds the K-1 has a footnote page that changes the allocation, and stops to think about it. Marks the job ready.

Every one of those steps is real work. Only two of them require a qualified person: the thinking about the footnote, and the final judgement that the return is ready. The rest is translation, and it is being done by someone whose value to you is judgement.

There is a second cost that partners feel more than they measure. Because the translation happens inside one person's head at their desk, nobody else can see how far along a return is. A job sitting in "documents received" tells you nothing about whether it is ten minutes or three hours from reviewable. So partners ask, staff report, and both spend part of every day on status instead of work.

Why buying a scanning tool did not fix this

Plenty of firms have already tried. The honest read from practitioners who did is that the tools handle the easy part and hand back the hard part.

A tax form's face page is fixed. The boxes are in the same place every time, they hold single numbers, and machines read them well. That part is genuinely solved, and if you are still typing W-2 boxes by hand you are wasting money.

What the tools struggle with is everything stapled behind the face page. Footnote allocations that are written as prose rather than boxes. State schedules whose apportionment percentages moved since last year. A single K-1 reporting several activities where the passive loss limits apply per activity, which several tools flatten into one combined figure that is arithmetically correct and useless. Handwriting. A consolidated brokerage statement that one tool insists is a single document.

The result is the complaint you hear in every practitioner forum from firms who bought one: they spent about as long fixing the inputs as they would have spent typing them. That is not a reason to skip automation. It is a reason to be precise about what you automate, and to stop treating "the tool reads documents" as the finish line.

What actually closes it

Credit where it is due first, because this is a moving target. Karbon added smart tax organisers and document handling through a partnership at the end of 2025, and that partner does rename, categorise and validate documents, and pulls prior-year information out of tax software backups. Jason Ackerman, a CPA at BNA CPAs and Advisors, said of it: "This integration alone will save about 20 minutes per return, in addition to the 30 minutes we already save." That is a real named person putting a number on his own firm's result, and it is worth having.

What that does not do is stand between the pile of client documents and the fields in your return. That is the piece still missing, and it is what we build.

The shape of it, in business terms rather than mechanics. Documents arrive however the client sends them, which is to say badly. Before anyone opens anything, the system reads the whole set, works out what each document is, checks it against what this client sent last year, and pulls the figures off the face of each one. Those figures go into the job where your preparer will actually see them, next to the source page they came from.

Then the important part, which is the part vendors skip. The job does not flip to ready because files arrived. It flips to ready when the set is actually complete and the figures reconcile. If the client sent three of four expected 1099s, the job stays put and the missing one becomes a specific request rather than a general nag. If something looks wrong, a footnote that does not parse cleanly, a state percentage that moved, an amount that disagrees with last year by more than it should, that single item goes to a person with the page open and last year's number beside it.

Your preparer stops being a typist and becomes a reviewer. They open a compiled file with eleven flagged items instead of a folder with forty documents. And because completeness is now a fact the system knows rather than a judgement in someone's head, a partner can see which returns are genuinely ready without asking anybody.

This is the same work as any tax document automation for a CPA firm, and it is the piece of the wider gap around Karbon that pays back fastest at volume.

Where this gets uncomfortable, and it should

The obvious objection is the right one. If a machine is reading client tax documents and writing numbers toward a return, who is responsible when it is wrong?

You are. That does not change and should not. Which is why the only defensible design is one that reports its own uncertainty honestly. A system that quietly guesses at a section 199A allocation is worse than no system at all, because it removes the signal that somebody needed to look. The measure of a good build here is not how much it fills in. It is how reliably it admits what it could not read.

That has a practical consequence worth agreeing before anyone builds anything: who on your staff owns a flagged item, and does a flagged item block the job or merely annotate it. Firms answer that differently depending on how much they trust their seniors, and the answer changes the design. Any vendor who does not ask you that question has not built this before.

The second question is where the documents go. Client tax documents are the most sensitive things your firm holds, and "it runs in the cloud" is not an answer. The honest version is that this can run inside your own environment, so the documents never leave infrastructure you control, and every read and every write is logged in a way you could show a reviewer. If a vendor cannot tell you which of those two shapes they are selling you, that is your answer.

FAQ

Do we have to replace our scanning tool?

No, and you probably should not. Keep it for the face pages, where it is reliable and cheap. What you are adding is the layer that handles what is stapled behind the face page, decides whether the set is actually complete, and puts specific items in front of specific people. Replacing one scanning tool with another scanning tool reproduces the same problem with a different logo on it, because they all share the same limit: they read what is printed and then stop, because deciding what it means requires knowing tax.

Does this work if we prep in UltraTax or Lacerte rather than ProConnect?

Yes, and this is exactly why it has to be built rather than bought. Karbon publishes no integration with Lacerte, UltraTax CS, Drake, ProSystem fx or ProSeries, so there is no product you can switch on that closes this for you. What can be done is to have the compiled, checked figures land in the format your prep software actually accepts, so your preparer starts from populated data instead of a folder. The work is specific to the engine you use, which is why the first question we ask is which one that is.

How long does this take to be useful in a season?

It should be handling your highest-volume, most repetitive document families before the season it is built for, and it should get better through that season as your preparers correct it. Be suspicious of anyone promising a system that handles every client's quirks on day one. The sensible path is to pick the two or three document types that generate the most retyping in your firm, get those genuinely solid, then widen. A narrow thing that works beats a broad thing that needs babysitting in March.

Will this reduce the number of preparers we need?

That is not what firms use it for, and the arithmetic usually points the other way. The scarce thing in filing season is qualified attention, not headcount. Every firm we have discussed this with wants the recovered hours going into returns they currently decline, or into finishing the season without the overtime. The judgement stays where it is. What leaves is the typing.