Summary

Document processing automation in an accounting firm covers three separate jobs. Сollecting files from clients, turning those files into usable data, and determining whether the firm has everything required to start or continue the engagement. Most software handles the first job well, and mature tax products also automate significant parts of the second for standardized documents. But the third remains much harder, especially outside predictable individual tax workflows.

That distinction is very important as buying another portal rarely removes the manual work that sits after upload. Someone still has to open the file, identify what it is, check whether it answers the request, and determine what is still missing. Recent document-extraction research also shows why sending every client document through one large AI schema is a poor production design. Reliability falls as the extraction task becomes broader and the required output grows.

For most accounting firms, the sensible path is to buy the standardized parts and automate the gaps around them. That usually means keeping the client portal or tax-document system that already works, then adding classification, narrow extraction, completeness checks, and exception routing where staff still spend review time. Before any client data enters that workflow, the firm also needs to establish where the data goes, who can access it, what the system is authorized to do, and how the workflow fits §7216 and the firm's Written Information Security Plan.

Three Problems Accounting Firms Keep Merging Into One

Let’s imagine that a client uploads a PDF and at first glance, the problem appears solved. The firm asked for a document, the client sent a document, and the file now sits inside the portal.

Then somebody opens it. It is the wrong statement period, or the client uploaded eleven documents as one PDF. This is why client document intake becomes confusing. Three different processes get compressed into one phrase.

Collection is a transport problem, intake is a data problem, and completeness is a reasoning and workflow-control problem. Accounting firms often buy software for collection and expect the remaining two problems to disappear with it.

The market itself is beginning to make this distinction more visible. Suralink, already established around PBC request management, launched document prescreening capabilities in June 2026 that compare an uploaded document against the original request and flag incomplete or inaccurate submissions. That product direction is revealing. Receiving the upload was never the end of the workflow. Somebody still had to determine whether the upload actually satisfied the request.

Canopy has moved in a similar direction. Its Smart Intake product now includes AI-generated questionnaires, document request lists, prefilled information, and uploaded-file matching. Again, the value is moving beyond a generic portal toward understanding what the firm asked for and what the client supplied.

That gives you the first diagnostic question before you automate anything: Where does your manual work actually begin?

If the answer is “we spend all day reminding clients to upload things,” you probably have a collection problem. 

If the answer is "the documents arrive, and then five people touch them before the information reaches the workpaper or tax system," you have an intake problem.

If the answer is "we never know whether the client is truly ready until a reviewer finds the gap," you have a completeness problem.

Those three answers lead to three very different investments.

Why More Reminders Eventually Stop Working

Accounting firms have spent years trying to solve late paperwork with increasingly sophisticated versions of the same idea: send another reminder.

Automation helps here. It can help considerably, but the mistake is assuming that five automated reminders will produce five times the compliance. The behavioral evidence says something more useful.

A field experiment involving Australian business taxpayers tested reminder letters for overdue tax debts. Receiving a reminder increased the probability of payment by about 25 percentage points compared with receiving no letter. Researchers then varied when the reminder arrived across a three-week period. Earlier reminders caused businesses to pay sooner, yet the final payment probability among the reminder groups was essentially the same.

Different context, same operational lesson: a reminder can pull work forward without changing who ultimately responds. 

For an accounting COO, that distinction matters because if a better reminder sequence causes 60 client files to arrive one week earlier, you have gained review capacity. Returns can enter preparation earlier. Managers see fewer artificial peaks. Review work moves away from the deadline.

That is a real operational result, and the system does not need to convert every chronically late client to create value.

A second piece of evidence makes the point stronger. Two large Dutch field experiments with 28,557 and 19,733 farming enterprises tested ways to move submissions away from a deadline peak. Giving people an earlier, non-binding target date moved roughly 4 to 5 percentage points of participants out of the peak period. Giving them a checklist did not improve submission timing. Reminding them that early submission meant early evaluation did not help either.

The intuitive response inside a firm is often: Maybe our checklist just needs to be clearer. Sometimes it does, but the evidence suggests that clarity alone will not solve procrastination.

What You Can Already Buy, and What You Probably Should Not Build

There is an easy way to waste money on document automation: rebuild a workflow that specialist software has spent years standardizing.

Individual tax document processing is the clearest example.

Thomson Reuters' SurePrep already handles a defined set of standard tax documents through 1040SCAN. Its current documentation describes a workflow that can read native PDF text layers directly and use OCR plus AI/ML techniques on supported scanned documents. The verification interface separately surfaces fields that need human review, and non-standard documents remain outside normal data capture.

Thomson Reuters also states that 1040SCAN currently auto-verifies OCR data for 65% of standard documents. That is a vendor-reported figure, so it should be treated as product evidence rather than an independent benchmark. The useful interpretation is the remaining share. Even inside a mature, specialized tax workflow, a meaningful portion of the work still requires verification. Thomson Reuters explicitly offers 1040SCANverify, where people perform that verification work.

This mechanism is more interesting than the percentage. For native PDFs, SurePrep can compare OCR output against the document's underlying text layer. It has a second source against which to check what it extracted.

Reliable automation often comes from agreement between independent evidence, rather than asking one model to become progressively more confident in its own answer.

Here is the practical boundary.

This is where the usual "OCR versus AI agent" conversation becomes unhelpful.

OCR solves character recognition. A document model can classify a page and extract meaning from less-standard layouts. Workflow logic determines where the extracted value goes. Rules and calibrated confidence determine whether a human needs to see it. Completeness logic compares what arrived with what the engagement requires.

Those are separate mechanisms, and putting all of them under the word "AI" hides the architecture you actually need.

A better way to think about OCR and AI

Suppose a client sends a monthly PDF from a regional bank.

You may need to:

1. determine that it is a bank statement,
2. identify the entity and account,
3. determine the statement period,
4. extract opening and closing balances,
5. verify those values against the source,
6. match the statement to the correct engagement,
7. determine whether another account is still missing,
8. route uncertain fields for review.

OCR may participate in step 4, but it does very little for steps 6 and 7. That difference is the reason a tool can advertise excellent OCR accuracy while your staff still spend hours managing intake.

Where AI Document Extraction Actually Breaks

The extraction question is usually framed badly. Companies often ask how accurate the model is. For production accounting, the better question is under what shape of task does accuracy deteriorate.

ExtractBench, an open benchmark published by researchers at Contextual AI in February 2026, is useful because it was designed around that question. The benchmark contains 35 PDFs across five domains, totaling 2,076 pages and 12,867 human-annotated evaluable fields. It tested six frontier models on structured PDF-to-JSON extraction.

There is a dramatic number in the paper: the aggregate field-level end-to-end pass rate was only 4.6%.

One exceptionally difficult domain, a 369-field financial-reporting schema, accounted for 84% of the benchmark's field evaluations. Every tested model failed to produce valid output on that schema. Remove that domain, and the aggregate pass rate rises to 28%. When output was valid, aggregate field-level accuracy was much higher, at 72.9%. The useful finding is therefore deeper than "AI extraction accuracy is 4.6%."

The useful finding is what made the systems fail.

The benchmark found schema breadth and required output volume to be much stronger failure drivers than document length or nesting depth by themselves. Some credit agreements ran for more than 100 pages and still performed relatively well because the requested output was narrow. A research-paper task had only 16 schema fields yet required enormous citation arrays, which made the output much harder. A deeply nested sports schema performed comparatively well because its structure repeated predictably.

That translates directly into an intake design rule: Do not ask one extraction step to understand the whole engagement. If a bank statement needs eight fields, extract eight fields.If a payroll register needs twelve different fields, use a payroll-register schema. Then combine the results downstream.

The alternative is one giant schema containing everything that might appear across every possible client document. It looks elegant on an architecture diagram. In production, you have increased the model's output burden and created more ways for a partial error to invalidate the result.

The benchmark found another counterintuitive result. Provider-specific structured-output modes were expected to help because they constrain a model to valid JSON. Instead, overall valid output fell from 51% to 37% in that experiment, partly because complex schemas collided with provider restrictions and complexity limits.

It means syntactically valid output and correct accounting data are separate controls, as a perfectly valid JSON object containing the wrong balance is still wrong.

Design for the failure you can afford

In accounting, a useful automation does not need to understand every page that enters the firm.

It needs to know what it can process reliably, what evidence supports the result, and when to stop.

Before Any of This Touches a Client File

This section deserves more attention than it usually receives. For U.S. tax practices, §7216 is a criminal provision.

Treasury Regulation §301.7216-1 defines disclosure broadly as making tax return information known to another person in any manner whatever. The regulation also defines tax return information broadly, including information furnished in connection with preparing a return and information derived from it. A knowing or reckless unauthorized disclosure or use can carry criminal penalties under §7216.

That matters when somebody says: "We have an enterprise AI account. The provider says it does not train on our data, so we're fine." Data-retention terms are important for security and vendor risk. They do not answer the entire §7216 question.

In a March 2026 practitioner analysis, Thomas Gorczynski and Josh Youngblood argue that entering tax return information into a third-party AI system constitutes a disclosure when that information leaves the preparer's control and reaches the AI provider. They also point out that the IRS has issued no AI-specific §7216 guidance. Their article is practitioner interpretation rather than IRS authority, which is exactly how it should be used.

The existing regulation does contain an important distinction.

Treas. Reg. §301.7216-2(d)(1) allows certain disclosures to another U.S. tax return preparer for preparation or auxiliary services without taxpayer consent, provided the service does not involve substantive determinations or advice affecting tax liability. The regulation defines a substantive determination as analysis, interpretation, or application of law.

That distinction should influence your architecture.

A bounded workflow that classifies documents, extracts values, transfers information, or performs mechanical processing presents a different §7216 analysis from a system deciding how a taxpayer should report an item, which deduction should be claimed, or how the law applies to the client's facts.

The closer automation gets to substantive tax judgment, the more carefully the authority, consent, and provider relationship need to be reviewed.

General-purpose AI tools make the analysis harder. Gorczynski and Youngblood's practitioner reading is that conventional tax preparation software generally fits the auxiliary-services framework more naturally because its purpose is tax preparation. They consider general-purpose AI tools less likely to fit that category, while acknowledging that the IRS has provided no AI-specific ruling on the issue.

If an exception does not apply and consent is required, the details matter.

For Form 1040 series taxpayers, Rev. Proc. 2013-14 establishes specific consent requirements. The IRS requires knowing and voluntary consent and prescribed language. The practitioner analysis also highlights the practical problem for firms using multiple AI vendors: a valid disclosure consent needs to identify the recipient, so a vague reference to "various AI tools" is not a sensible compliance strategy.

Then §7216 is only one layer.

Tax preparation firms are financial institutions under the FTC Safeguards Rule. The FTC requires covered firms to maintain an information security program and to select service providers capable of protecting customer information, put security expectations into contracts, monitor those providers, and periodically reassess them.

The IRS reinforced the same operating requirement in June 2026: tax professionals need a Written Information Security Plan tailored to the size, complexity, and sensitivity of the practice, including controls around service providers. IRS Publications 4557 and 5708 provide the implementation guidance and WISP framework.

So before you connect any document-intake system to client files, answer these questions in writing:

That work can feel slower than signing up for another tool.

It is also the work that lets you defend the system later.

This section describes operational considerations, not legal advice. Firms should have their own qualified legal and tax advisers review the application of §7216 and other obligations to their specific workflow and vendor arrangements.

How Codebridge Approaches Document Intake Automation

When we look at a workflow like this, we start with the sign-off problem.

• What information must be available before somebody can continue the engagement?
• Which parts are deterministic?
• Which mistakes would create rework?
• Which mistakes could create a reporting or compliance issue?
• Where does a person need to retain authority?

Then we take a sample of the firm's actual documents and build the smallest workflow that can answer those questions.

The pattern is familiar from other high-stakes systems we have built, even though those projects were in different domains.

In our RadFlow AI work, the important architecture decision was not simply whether AI could analyze clinical information. The system had to fit into the existing workflow and preserve clear human review boundaries where clinical responsibility remained with the radiologist.

We have used the same principle in multi-step commercial automation: routine actions can move quickly when rules are satisfied, while actions outside the approved authority boundary stop or escalate.

Document intake needs the same discipline: the model can classify, and the model can extract.

The surrounding system still needs to determine what evidence is required, what can move automatically, and where the firm insists on review.

For accounting firms, we also prefer architectures where the firm owns the resulting workflow and can run it inside an environment appropriate to its security requirements. That reduces dependence on another opaque workflow vendor and gives the firm much more control over data movement, integrations, audit trails, and future changes.

If you are evaluating document intake automation, start with one workflow and one real document set. A 30-minute scoping call is enough to determine whether the problem is collection, extraction, completeness, or a combination of the three.