An Entry ID Scheme for AI-Drafted Files: One Name in Every Log

A Reviewer leaves a note on "the interest line." The Preparer clears it by fixing "row 14." The hand-edit log records a change to "brokerage income," and the reopen log lists "the statement entries." Those may all be the same entry, and nobody can tell without laying every log side by side.

An entry ID scheme fixes that with one name per entry. In the approach below, the Firm writes a short pattern (section, source, number), a Preparer gives each entry its ID when it first goes on the entry list, and every log after that quotes the ID instead of describing the entry. The plugin drafts; the Firm's preparer prepares; the Reviewer signs off. The IDs are the Firm's own names for its entries, written by its people and kept in whatever systems it already uses.

This piece gives the ID pattern with made-up examples and a one-page rules list the Firm can paste into its procedures. It sits beside one vocabulary for AI-drafted work, which fixes the status words; this one fixes the names of the entries those words describe.

Why entries need one name

Each log gets written by a different person at a different moment. The Preparer describes an entry by its label, the Reviewer by its place on the list, and whoever reopens the file by the document it came from. Each description is honest, but they don't line up.

Row positions are the weakest name of all. Insert an entry or sort the list a new way and every row below it moves, so a note that said "row 14" now points at something else. Labels drift too: two entries can share a label, and a hand edit can change one. An ID that stays put for the life of the file takes the guesswork away.

The ID pattern

The pattern has three parts, joined by hyphens:

[section code]-[source code]-[number]

• Section code: a short code for the part of the entry list the entry sits in, such as INC for Income or EXP for Expenses.
• Source code: a short code for the entry's source document, taken from the client folder's file index.
• Number: a two-digit count within that section and source, starting at 01.

If the Firm names files as in setting up the client folder before any AI pass, the source code can be a short form of the file name.

Some made-up examples:

The number belongs to the source, so a new document never shifts the numbers on entries from another one. An ID says where an entry sits and where it came from, and nothing about whether it's right.

Who writes the IDs

Under this approach, a Preparer gives each entry its ID when the entry first goes on the list, after the AI pass and before anyone checks or edits a row. An entry a person keys in later gets the next unused number for its section and source.

From then on, the ID is part of the entry. Nobody changes it to tidy the list or writes a new one over it.

Where the ID goes

The Firm can quote the same ID everywhere it writes about an entry:

• The entry list: the ID sits in its own column, first on the row.
• Review notes: each note opens with the ID of the entry it's about, then the note itself, as in "EXP-CARD-04: the page shows separate charges on this line."
• The hand-edit log: each edit row starts with the ID, ahead of the edit fields.
• The reopen log: the touched-entry list on each row is a list of IDs.

The hand-edit fields follow marking hand edits on an AI-drafted entry list, and the touched-entry list follows the reopen log in a late document after sign-off.

Each quote matches the list letter for letter, with nothing shortened or swapped for a description. A search of the review notes for an ID then finds the notes about that entry.

Splits, merges and struck entries

When an entry changes shape after it has an ID, each rule below keeps the old ID on the list, so every note that quoted it still points at something.

• Split: the original entry keeps its ID and is marked "split into," with the new IDs listed. Each new entry takes the original ID plus a letter and names the original ID on its row.
• Merge: each original entry keeps its ID and is marked "merged into," with the new ID. The merged entry takes the next unused number for its section and source, with a note naming the IDs it came from.
• Struck: an entry that shouldn't be on the list is struck through, not deleted, and keeps its ID, marked struck, with the reason.

No renumbering after review

Under this approach, a Preparer can correct an ID before the file first goes to the Reviewer, as long as no note quotes it yet. After that, every ID is fixed for the life of the file, through send-backs, hand edits and a reopen.

Gaps in the numbers are fine. A gap means an entry was struck, split or merged, and its old row shows which. Closing the gaps would break every note that quoted the old IDs.

The rules list

The Firm can paste this page into its procedures and change any line to fit.

• Every entry on the list has its own ID in the form [section code]-[source code]-[number].
• The Firm writes the section codes and source codes; a Preparer gives each entry its ID when it first goes on the list.
• Numbers count up within each section and source, starting at 01.
• A corrected copy of a document keeps the source code of the copy it replaces.
• An ID is never reused, even after its entry is struck, split or merged.
• Once the file has gone to the Reviewer, no ID changes and nothing is renumbered. Gaps stay.
• A split entry keeps its ID, marked "split into"; each new row adds a letter and names the original ID.
• Merged entries keep their IDs, marked "merged into"; the merged entry takes the next unused number and names the IDs it came from.
• A struck entry keeps its ID, marked struck, with the reason.
• The entry list, review notes, hand-edit log and reopen log quote each ID exactly as it reads on the list.
• An ID helps the Reviewer find an entry. It doesn't change what the Reviewer reads or signs off.

What the IDs don't change

The scheme names entries. It doesn't check them, and a full set of IDs doesn't show that the list is complete. The Reviewer still reads the entries against their sources and decides what holds. Every file ends with the Reviewer's sign-off, on the whole file.

A Doe example

The names and file below are made up for illustration.

Jane Doe, the Preparer, works the synthetic Doe Holdings file. She gives each drafted entry a complete ID before checking anything, using the Firm's section and source codes.

Pat Doe, the Reviewer, writes a note on EXP-CARD-04: the page shows separate charges on that line. Jane assigns EXP-CARD-04a and EXP-CARD-04b, names EXP-CARD-04 on both new rows and marks the original as split into them. She logs the original and new IDs and replies to the note with them for Pat to check. Pat checks the new entries against the page and signs off on the whole file.

Later the client sends a corrected brokerage statement. Jane asks Pat to reopen the file. Pat reopens it, and Jane writes the touched entries on the reopen log as INC-BRKA-01 and INC-BRKA-02. Pat reads every log by the same IDs, checks the entries against their pages and signs off on the whole file again.

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.