How to Review AI-Assisted Work Before Including It in a Client Invoice

AI-assisted work can leave a misleading trail. A long session may end in a useful change, an abandoned approach, a review task, or nothing ready to deliver. Token use and time at the keyboard are records of activity. They are not, by themselves, a billing rationale.

Before you prepare an invoice, review the work as a chain: what client and task it belonged to, what happened during the session, what outcome you can document, and what remains uncertain. This makes the eventual invoice easier to explain without pretending that every AI interaction created client value.

1. Set the review boundary before reading the activity

Start with four fields: the client, project, task or workstream, and billing period. Write them down before looking at individual sessions. This prevents a common mistake: interpreting a busy day first and trying to assign it to the right engagement afterward.

If one task served more than one client, do not force the whole session into a single bucket. Split only where you can explain the division from the work context. If you cannot tell which engagement a segment belongs to, mark it as unresolved for now.

This boundary also helps distinguish billable work from adjacent activity. Research, setup, internal planning, support, debugging, and client-requested delivery can all look similar in an activity record. The relevant question is not simply, “Was I active?” It is, “What was I working on for this client during this period, and what can I accurately say about it?”

2. Inspect the session evidence in context

Review each relevant AI session next to the project and task context. Look for the available facts first: session time, a short session title, token and cost context, and its connection to a project or task. These details help reconstruct the sequence of work without turning a token total into a proxy for importance.

LogAgent tracks AI-agent session time, tokens, costs, commits, and short titles from local session logs. That can give you a starting record, but the review still needs your judgment. A session titled around an implementation task may have involved useful exploration, rejected suggestions, or a finished change. Treat the title as context, not a verdict.

Use a simple note for each session or group of related sessions:

• Supported facts: what the record shows, such as the project association, session timing, and documented output.
• Work interpretation: the plain-language description of the work you reviewed.
• Open question: anything the record cannot settle, such as whether an exploratory branch was used or whether a task changed scope.

Keeping these categories separate is practical. It stops an interpretation from being written as though it were raw evidence, and it leaves a clear place for questions that need checking before billing.

3. Check outcomes, but do not reduce work to commits

Next, look for documented outcomes. A relevant commit can help connect AI-assisted activity to a change in a codebase. Task updates, review notes, or other project records can add context where they are available. The aim is traceability: can you explain how the session relates to a real piece of work?

A commit is useful evidence, but it is not an automatic proof of value or billability. A small commit may follow substantial investigation. A larger commit may include work from several sessions or people. Some legitimate work, such as analysis or review, may not result in a commit at all. Conversely, a reverted change may show that work occurred without establishing that the full effort belongs on a client invoice.

LogAgent links AI sessions to commits, tasks, projects, and invoice lines. Use those links as a review path, not as an automatic billing rule. Follow the path from session to task and outcome, then ask whether the description you plan to use is accurate, proportionate, and understandable to someone outside your workflow.

When the answer is unclear, do not fill the gap with a confident narrative. Flag the segment for review. It may need a project-note check, a conversation with the person who owns the scope, or exclusion from the current invoice until you can describe it honestly.

4. Write a short rationale that can survive a question

After reviewing the evidence, write the invoice rationale in one or two plain sentences. Describe the work, its project context, and the documented outcome where one exists. Avoid presenting AI usage itself as the service delivered.

For example, a rationale can follow this structure:

Reviewed and implemented changes for [task] in [project], including investigation and validation of the requested behavior. Related work was checked against the recorded task and documented project outcome.

Replace only the bracketed details with information you can support. If the outcome is still unresolved, say less, not more. A narrow description is better than a polished claim that merges assumptions with facts.

Before finalizing, make one last pass: confirm the client and period, check that each included segment has a project or task context, verify any stated outcome, and isolate disputed or incomplete work. It is a repeatable way to make your own review more careful before you decide what to include.

An evidence-oriented record is most useful when it preserves both the trail and the uncertainty. LogAgent uses explainable rules and heuristics and routes disputed segments to review, which supports that kind of pre-invoice check instead of forcing every recorded minute into a conclusion.