The Coverage Check: Does Every Client Document Show Up in the AI-Drafted Entry List?

The entry list is drafted and the totals tie. One question is still open: does every document the client sent show up somewhere? On the entry list, a document with no entries is simply absent, and the list alone doesn't say why.

A document coverage check for an AI-drafted file answers that question by hand. The Preparer walks the file index the Firm built at setup and, for each document, writes the entry IDs where it shows up in the entry list or a short reason it has none. The plugin drafts; the Firm's preparer prepares; the Reviewer signs off. The coverage check is a person's step inside that chain, done in whatever systems the Firm already uses.

This piece gives a paste-ready coverage sheet, a list of no-entry reasons the Firm can adapt, a run order and a Doe example. The index itself comes from setting up the client folder before any AI pass; this check picks it up after the draft.

What the coverage check confirms

A tie-out compares totals, as in footing AI-extracted totals back to the source. It tells the Preparer whether a document's numbers agree with the entry list, not whether every document on the index has been accounted for.

The coverage check works at the level of the document. It confirms the entry list against the index: every row on the index gets an answer, and every answer is written where the Reviewer can read it. It doesn't judge whether an entry is right. That stays with the Preparer's own review of each entry and, in the end, with the Reviewer.

Each document ends with one of two answers:

• Entry IDs. The document shows up in the entry list, and the sheet names every entry that cites it.
• A no-entry reason. The document has no entry, and the sheet says why, in words from the Firm's list.

A row with neither gets a look by hand. In this method, the Preparer opens that document by hand before sending the file to the Reviewer.

The coverage sheet

The sheet has one row per document on the index, including documents set aside at setup. The Firm can paste this table into its procedures and add columns.

Under the table, the Preparer writes three lines:

• Index rows: [count]. Sheet rows: [count]. The two agree: [yes or no].
• Entries on the entry list whose source isn't a row on the sheet: [none, or entry IDs].
• Completed by [name], on [day].

No-entry reasons the Firm can adapt

The Firm writes its own list, so everyone uses the same words. A starting set:

• Duplicate of [file name]. A true copy set aside at setup. Its twin carries the entries.
• Superseded by [file name]. A later version replaced it, and the current copy carries the entries.
• Not for this file. The document belongs to another client file, or it holds nothing this file uses, such as a cover note. The note column says who decided.
• Waiting on client. The document is incomplete or a replacement was asked for. The note column points to the request.
• Page can't be read. A clean copy was requested, and the note names the page.
• Question for the Reviewer. The Preparer can't settle whether the document belongs in the entry list. The note states the question.

Marking which copy is current is covered in two copies of one statement.

For a document still waiting on the client, the note can point to the chase log from the follow-up cadence for the client request list.

A reason that isn't on the Firm's list counts as blank. So does "N/A" or "didn't apply," because a later reader can't tell what was decided.

A run order the Firm can adopt

In this method, the Firm runs the check after the Preparer's own entry review and before the file goes to the Reviewer. The Firm can set a different order; these steps are one way to write it down.

1. Open the file index as it stood after the setup check, with its initials.
2. Copy every index row onto the coverage sheet, set-aside rows included, and write both counts.
3. For each row, read the entry list's source column for that document's name and write every entry ID that cites it.
4. For each row with no entry IDs, write a reason from the Firm's list.
5. Open every row that still has neither and look at the document by hand. Then add the entry by hand under the Firm's hand-edit steps and write its ID, or write a reason from the Firm's list; for an unresolved question, write "Question for the Reviewer" in the No-entry reason column and the question in the Note column.
6. Read the entry list the other way. The Preparer writes the entry ID on the line under the table for entries whose source has no sheet row, together with the source name and a question for the Reviewer.
7. Initial the sheet and put it in the file beside the entry list.

What goes to the Reviewer

The coverage sheet sits in the file next to the entry list. The Reviewer reads it with everything else: which documents produced which entries, which have none and why, and any question the Preparer couldn't settle.

The sheet is the Preparer's record, not a decision on the file. In this method, the Reviewer can accept the reason, ask for more or send the row back; the Preparer updates the sheet and any related entries by hand, and the Reviewer reads the changes before signing off on the whole file. The Reviewer signs off on the whole file, sheet included. No file is done without the Reviewer's sign-off.

A Doe example

The names and file below are made up for illustration.

Jane Doe, a Preparer, runs the coverage check on the synthetic Doe Holdings file. Pat Doe is the Reviewer.

Jane copies every index row onto the sheet, and the counts agree. Jane reads the source column and writes the entry IDs beside the bank statements and the corrected brokerage statement. The duplicate scan of a bank statement gets "Duplicate of" with the name of the clearer copy. Jane writes "Superseded by" with the corrected file's name beside the original brokerage statement.

Some rows are still blank after that pass. The client's cover letter has no entries and no reason. Jane opens it, sees it only lists what the client sent, and writes "Not for this file" with her initials. A loan statement has no entries either. Jane can't settle from the page whether it belongs in the entry list, so she writes "Question for the Reviewer" in the No-entry reason column and her question for Pat in the Note column.

Reading the entry list the other way, Jane comes to an entry whose source names a file that isn't on the index. The client uploaded it after setup. Jane doesn't edit the index. Jane writes the entry ID and source name on the line under the table, together with her question for Pat.

Jane initials the sheet and puts it beside the entry list. Pat accepts the cover-letter reason and asks Jane to add an entry for the loan statement by hand and an index row for the late upload under the Firm's setup steps. Jane adds the loan entry and records its ID, clears that row's reason and question, and adds the late upload to the index and sheet with its existing entry ID. She updates both counts and writes "none" for entries without a sheet row. Pat reads the changed rows and signs off on the whole file.

Where TracePrep fits

We've built a TracePrep plugin that drafts these steps in your Firm's workflow, while your preparer decides and your Reviewer signs off. Join the waitlist and we'll tell you when plugin access opens.

Get on the list for plugin access

This is general information, not tax or legal advice. In TracePrep's workflow, the plugin drafts, the Firm's preparer prepares, and the Firm's Reviewer signs off. Access to the plugin is by waitlist. Keep client data inside the systems your Firm has approved.