Who Can Change What on an AI-Drafted File: Preparer, Reviewer and Admin Roles

An AI-drafted file passes through several hands. The Preparer edits the drafted entries, the Reviewer writes notes, and someone keeps the Firm's AI instructions up to date. When nobody has written down who may do what, a Reviewer can quietly fix an entry, a signed file can change with no record, or an instruction can change mid-season with nobody able to say who approved it.

A rights table for an AI-drafted file settles that before the season starts. It lists each action on the file, says whether the Preparer, the Reviewer or the Admin may take it, and names what gets recorded when they do. The plugin drafts; the Firm's preparer prepares; the Reviewer signs off. The table is a Firm policy, not a software setting, so the Firm can run it in whatever systems it already uses.

This piece gives a role-by-action rights table, a reopen-after-sign-off log row and a quarterly check of who holds which role. Every file ends with the Reviewer's sign-off, and no role, tool or admin signs off in the Reviewer's place.

Three roles, defined once

The Firm writes each role as a job on one file, not as a job title. One person can be a Preparer on one file and a Reviewer on another.

Preparer. Works the drafted entries against the source documents, edits what's wrong, marks each entry checked and answers review notes.

Reviewer. Reads the prepared file, writes review notes, decides how each one closes and signs off. Under this Firm-written table, the person who prepared the file isn't the person who signs it off as Reviewer.

Admin. Keeps the role list and the Firm's AI instructions in order. The Admin doesn't touch entries, notes or the sign-off. A partner can hold the Admin role, and so can an office manager; the table describes the work, not the seniority.

When one person holds two roles

A small Firm may not have a separate Admin, and a partner may prepare some files and review others. That's fine, as long as the table still holds on each file. The person who edited and checked the entries on a file isn't the person who signs it off.

Where the Admin also holds a Reviewer role, a different Reviewer approves instruction changes that person wrote. The same idea runs through the table: on any one file, the person who makes a change isn't the person who approves it.

The rights table

The Firm can adapt the working details of this table; every file still ends with the Reviewer's sign-off, and no other role signs off in the Reviewer's place. "Yes" means the role takes the action. "Asks" means the role requests it and someone else decides.

Two rows carry most of the weight. Under this table, the Reviewer doesn't edit entries, because an entry the Reviewer changed is an entry nobody else checked. The Admin doesn't sign off, close notes or mark entries checked, because keeping the list in order isn't the same job as checking the work.

The record column matters as much as the yes and no columns. If an action happens and nothing is written down, the Firm can't tell later whether the table was followed.

The Preparer keeps the drafted value on the row when editing, as described in marking hand edits on an AI-drafted entry list.

Review notes stay with the Reviewer

The Preparer answers a note but doesn't close it. Closing is the Reviewer's call, and the note shows how it closed: fixed, explained, or carried as an open item.

When the two disagree about an entry, the note holds both readings until it's settled. The Firm's steps for that live in when the Preparer and Reviewer disagree.

Reopening a file after sign-off

A signed file sometimes needs to change. A client sends a corrected document, or someone spots an entry that doesn't match its page. The table says who may reopen it and what the record keeps.

Under this approach, the Preparer or anyone else on the file asks; the Reviewer reopens. The original sign-off stays on the record. Nobody deletes or rewrites it. The reopened file then goes through the same steps as before: the Preparer edits and marks checked, the Reviewer reads, and the file ends with a new Reviewer sign-off.

The reopen log keeps one row per reopening:

A row with an empty last cell is a file that's open again and not yet signed. The Firm can read the log at each week's file meeting so those rows don't sit.

Changing the Firm's AI instructions

The Firm keeps a written version of the instructions it has chosen for use with each file. Under this table, the Preparer who spots a problem asks for a change, the Admin writes the new version, and a Reviewer approves it before it's used on a client file.

The Firm records the instruction version chosen for each file, alongside what changed and who approved it. Building and versioning the instructions themselves is covered in writing instructions for an AI tool on tax documents.

The quarterly role check

People join, leave and change jobs, and the role list drifts. The Firm can run a short check each quarter, with the Admin running it and the partner reading the result.

1. Pull the current role list: every name and the roles each one holds.
2. Compare it with who works at the Firm today. Remove anyone who has left.
3. For each remaining name, confirm the roles still match the person's job.
4. Check open files: nobody is both Preparer and Reviewer on the same file.
5. Check the instruction record: each version since the last check names an approver.
6. Check the reopen log: each row has a reason, and each closed reopening has a re-sign-off.
7. Write the date, who ran the check, what changed and who approved each change at the top of the role list.

The check takes a short meeting. Without it, a person who left in the spring can still show up as a Reviewer in the fall.

A Doe example

The names and file below are made up for illustration.

Doe & Co. CPA writes its rights table with the eight rows above. Alex Doe is the Preparer on the synthetic Doe Holdings file, Pat Doe is its Reviewer, and Sam Doe is the Admin.

Pat signs off the file. The client, Jane Doe, then sends a corrected document. Alex asks to reopen, Pat reopens and the log gets a row: asked by Alex, reopened by Pat, reason "corrected document from client." Alex edits the affected entries, keeps the drafted values beside the edits and marks the entries checked. Pat reads the changed entries and signs off again. The first sign-off stays on the record next to the second.

At the quarterly check, Sam compares the role list with current staff and jobs. On the partner's say-so, Sam removes departed staff from the role list and updates roles and future-file assignments to match current staff and jobs. For open files affected by departures or changed roles, Sam records a current Firm Reviewer on the partner's say-so. That Reviewer did not prepare the file, reviews the prepared file and signs off. Earlier sign-offs stay on the record. Sam records who ran the check, what changed and that the partner approved each change.

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.