Two Preparers, One AI-Drafted File: Splitting the Work Without Losing Track

A large file lands with more work in it than one Preparer can finish in time. The Firm splits it: one Preparer takes the bank and brokerage documents, another takes the rental and business documents, and both start the same morning. Working in parallel shares the workload, with coordination and merge work to account for. It's also how an entry gets checked twice, or not at all, without anyone noticing.

Splitting an AI-drafted file between two preparers goes better when the Firm settles three things before the split starts: who owns each section and each drafted entry, where open items go, and what check runs before the file reaches review. The plugin drafts; the Firm's preparer prepares; the Reviewer signs off. The split shares out the preparing. It never splits the sign-off.

This piece gives a section split table, a merge-check checklist, and a conflict log row the Firm can paste into its procedures. Passing a whole file from one person to the next is a different job, covered in the handoff note for an AI-drafted file.

Where a split goes wrong

Without a plan, a split leaves gaps at the seams. A document that feeds two sections gets entered by both Preparers. A drafted entry nobody claimed sits unchecked, because each person thought the other had it. One Preparer edits a shared entry, the other changes it back, and neither records the disagreement. Open items end up on two lists, and the client gets the same question twice.

These gaps may reach review and send the file back for more preparation. The fix is to decide ownership at the start and check it at the end.

Split by section, own every entry

The Firm splits the file along its source sections, so each Preparer works from a separate set of documents. Before anyone starts, the manager on the file fills in a split table, one row per section. The table, the open-items list and the conflict log below are records people keep, in whatever systems the Firm already uses.

The Firm can set a few rules to keep the table honest.

• Every section has exactly one owner. A row with two names is really two sections, so split it again.
• Every drafted entry belongs to the section its source document sits in, so it has one owner too.
• A document that feeds both sections goes on the shared row with one owner by name. Nobody leaves it to both.
• The AI pass runs once on the whole client folder before the split. Each owner then works only the drafted entries in their own section and records the day they start.
• Only the owner of a row changes its status.

Each owner runs the preparer self-review on their own sections before marking them self-reviewed.

One open-items list

Under this approach, the two Preparers keep one open-items list for the file, not one each. Every row names the section, the item, its owner and the next step.

A question for the client goes on the list before it goes to the client. That way the other Preparer sees it's already been asked and adds to it, instead of sending a second request.

When an item touches the other Preparer's section, its owner tags that Preparer by name on the row. The tag asks for an answer; it doesn't move the item, and only the owner closes it.

The merge check

Before the file goes to review, someone who didn't do the work checks the seams. The Firm picks who: each Preparer checks the other's sections, or a manager checks both. The checker writes their name and the date at the top, then works down the list.

• Every row on the split table shows one owner and a status of self-reviewed.
• The checker confirms that every drafted entry has an owner and no entry has competing owners.
• No document was entered in two sections. Where a document feeds both, the shared row names the one owner who entered it.
• Every document in the folder maps to a section. A document with no section goes back for an owner and a recorded check.
• The entry count across both sections matches the entry count on the file.
• Every open item sits on the one shared list with an owner and a next step. No private lists are left.
• Every conflict is on the conflict log with a resolution and a reason. No row has a blank resolution.

Under the Firm's rule, if a line fails, the file goes back to the owner of the section involved, not to both Preparers. When every line passes, the checker marks the split table merged and the file is ready for review.

The conflict log

A conflict is any entry both Preparers changed, or any place where their sections disagree, such as the same document read two ways. Each one gets a row:

The entry's owner resolves it against the source page. If the two Preparers still disagree, the manager on the file decides, and the row says so.

Nobody settles a conflict by typing over the other Preparer's entry. The view that wasn't kept stays on the row, so the Reviewer can read both.

The Firm can mark the changed entry with the same hand-edit marks it uses on the entry list.

What the Reviewer sees

The Reviewer gets one file, not two halves. The split table sits at the front, the completed merge checklist under it, and the conflict log after that. Before reading a single entry, the Reviewer knows who worked each section and where the two Preparers disagreed.

A note sent back goes to the owner of the section it concerns, and only that owner answers it. Every file ends with the Reviewer's sign-off, and a split file gets one sign-off for the whole file, not one per section.

On the Firm's status board, a split file stays one row with one owner, and its note names the split.

A Doe example

The names and file below are made up for illustration.

Morgan Doe, a manager at Doe & Co. CPA, splits the synthetic Doe Holdings file. Alex Doe owns the bank and brokerage section. Sam Doe owns the rental and business section. A loan statement feeds both sections, so Morgan puts it on the shared row with Sam as owner. The AI pass has already drafted the whole folder. Alex works the bank and brokerage entries, and Sam works the rest.

Alex and Sam record their section entries, with Sam's list also including the shared statement's entries. Before checking the table, Alex edits an entry from the loan statement. Sam edits the same entry the next day. Sam logs it on the conflict log, resolves it against the source page, and keeps Alex's view on the row. Alex tags Sam on the open-items list with a question about the statement, instead of writing to the client.

Both mark their sections self-reviewed, and Morgan runs the merge check. Morgan confirms that every entry has an owner and no entry has competing owners. Morgan reconciles the section lists, including the shared statement's entries, to the merged file. The conflict log records the resolved disagreement, and the shared list records the statement question with its owner and next step.

Morgan marks the table merged. Pat Doe, the Reviewer, reads the split table, the merge check and the conflict row, then reviews the whole file. Pat sends a note back to Alex, Alex clears it, and Pat signs off on the 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.