Audit row-level time coverage when a timesheet is marked billed

The problem

A mixed-project timesheet can carry a whole-sheet billed label while only some time rows have invoice coverage. A useful review must distinguish genuinely unmatched minutes in a complete supplied ledger from absent links, cancelled documents and known reversals; it cannot infer chargeability from a header status.

Agent job

Build a row-to-invoice coverage ledger from minimized copies, reconcile signed coverage movements under supplied state rules, and explain discrepancies between row evidence and the sheet-level label.

Expected output

A draft time_coverage.csv, document_link_exceptions.csv and billing_review_questions.txt showing source-linked coverage, uncovered minutes where provable within the supplied scope, unresolved rows and header conflicts. No invoice or charge recommendation.

Why an agent / simpler alternative

The useful agent work is reconciling differently labelled export states, explaining ambiguous links and assembling source-linked questions across several copies. Event identity, joins and minute arithmetic should be deterministic and inspectable. A native row-level invoice-coverage report or a stable spreadsheet pivot is simpler and preferable when it already captures reversals and complete history; a clean one-file subtraction alone is weak agent fit.

Who this helps

1. Project controller

2. Billing operations specialist

Before a pilot — required, unexecuted

1. Obtain a specific owner-authorized synthetic test scope, processing environment and retention plan, and create an independent expected-result oracle before executing the proposed workflow.

2. Confirm a present unresolved owner need in the target installation/version and compare the complete output and total review effort with the native or deterministic alternative; stop if the simpler control is sufficient.

3. Verify actual account eligibility, task-specific file/tool support, access limits and costs before testing; no connector installation, purchase, upload or access provisioning is authorized by this plan.

4. Before an authorized fixture, specify decimal-hour to minute precision/rounding, namespace uniqueness, cancellation versus signed credit rules, reversal-of-reversal treatment and the affected-row propagation rule for orphan links. Have the independent owner create exact event and null-state expectations.

5. Retain E5 as an isolated overcoverage variant with exactly 90+60 coverage against 120 duration; do not append those events to a base row. Include conflicting duplicate IDs, negative net coverage and incomplete customer partitions, and verify that no resolved grand total hides them.

Evidence boundary

Problem-source and occupational context are separated from this original procedure. All six steps, prompts, output schemas, synthetic numbers, acceptance criteria and value hypotheses are authored proposals, not source-derived instructions or demonstrated agent results.

Setup requirements

1. Restrict the first proposed test to synthetic project codes and durations. Keep all employee names, client personal contacts, compensation and performance fields out.

2. Provide immutable row and coverage-event IDs with namespaces, an explicit state table, a single cut-off/time zone and complete posted/reversed/cancelled coverage. Header-only exports are insufficient.

3. Use raw minutes or an explicit hours-to-minutes convention, preserve sign and precision, and supply exact reversal links. No inferred retainer, rate, tax or contract rule.

4. Require an owner-written coverage manifest; when unavailable, the deliverable must be a data-gap report rather than an uncovered-hours total.

Inputs and access

1. Name

   timesheet_rows.csv

   Source or owner

   Synthetic project controller

   Sensitivity

   First test is synthetic only. Immutable sheet and row IDs, project/customer codes, raw duration and unit, owner-declared billing-scope flag, header status and export timestamp; no names, pay rates or staff performance data. A later owner-approved copy must remove personal data, credentials and unrelated content.

   Permission needed

   Before any future pilot, the accountable owner must authorize the exact synthetic or nonpersonal export copies, selected processing environment, scope and retention. Planning permission does not authorize that pilot.

   Scope

   Immutable sheet and row IDs, project/customer codes, raw duration and unit, owner-declared billing-scope flag, header status and export timestamp; no names, pay rates or staff performance data.

2. Name

   invoice_coverage_links.csv

   Source or owner

   Synthetic billing owner

   Sensitivity

   First test is synthetic only. Unique coverage-event ID, document/line ID, referenced time-row ID, signed covered quantity, document state, event time and reversal-of ID where applicable; no amounts, bank data or contact details. A later owner-approved copy must remove personal data, credentials and unrelated content.

   Permission needed

   Before any future pilot, the accountable owner must authorize the exact synthetic or nonpersonal export copies, selected processing environment, scope and retention. Planning permission does not authorize that pilot.

   Scope

   Unique coverage-event ID, document/line ID, referenced time-row ID, signed covered quantity, document state, event time and reversal-of ID where applicable; no amounts, bank data or contact details.

3. Name

   billing_state_and_scope_rules.json

   Source or owner

   Synthetic billing owner

   Sensitivity

   First test is synthetic only. Cut-off and time zone, which document states count, explicit quantity and reversal semantics, eligible row set and how duplicate export rows are recognized; no retainer quota or inferred entitlement. A later owner-approved copy must remove personal data, credentials and unrelated content.

   Permission needed

   Before any future pilot, the accountable owner must authorize the exact synthetic or nonpersonal export copies, selected processing environment, scope and retention. Planning permission does not authorize that pilot.

   Scope

   Cut-off and time zone, which document states count, explicit quantity and reversal semantics, eligible row set and how duplicate export rows are recognized; no retainer quota or inferred entitlement.

4. Name

   export_coverage_manifest.json

   Source or owner

   Synthetic export owner

   Sensitivity

   First test is synthetic only. File row counts, selected project/customer namespaces, invoice and credit/cancellation history coverage, date boundaries and known missing link fields; record whether completeness is confirmed or unknown. A later owner-approved copy must remove personal data, credentials and unrelated content.

   Permission needed

   Before any future pilot, the accountable owner must authorize the exact synthetic or nonpersonal export copies, selected processing environment, scope and retention. Planning permission does not authorize that pilot.

   Scope

   File row counts, selected project/customer namespaces, invoice and credit/cancellation history coverage, date boundaries and known missing link fields; record whether completeness is confirmed or unknown.

Proposed steps

1. 1

   Check required IDs, units, cut-off and extract coverage. Reconcile file row counts, confirm whether all relevant invoice/credit states and projects are represented, and isolate forbidden or out-of-scope fields. Treat the billed header as a comparison label, never as coverage evidence.

   Input: All four copies, snapshot times and owner-declared row scope

   Output: Intake manifest with safe scope, completeness assumptions and blocked partitions.

   Expected output: Intake manifest with safe scope, completeness assumptions and blocked partitions.

   Checkpoint: No absent invoice row is interpreted as unbilled time unless ledger coverage for that row is explicitly complete. Unknown completeness remains a blocking condition.

   Approval gate: Owner confirms the exact copies, cut-off and state definitions before a separately authorized test; do not retrieve missing records automatically.

2. 2

   Resolve exact row-to-document links within the supplied namespace. Separate repeated copies of the same event ID, distinct invoice events, orphan row references and project/customer conflicts. Retain each original row; do not join by worker name, task title or customer wording.

   Input: Time-row IDs and raw coverage-event IDs

   Output: Identity/link ledger with exact matches, repeated export events, orphan links and ambiguous scope.

   Expected output: Identity/link ledger with exact matches, repeated export events, orphan links and ambiguous scope.

   Checkpoint: Each input event appears once in an accepted or quarantined ledger; identical-looking distinct events are not deduplicated without owner evidence.

   Approval gate: Billing owner resolves ambiguous row IDs or mappings. An unlinked event that might cover several rows blocks those affected rows, not just the event.

3. 3

   Normalize quantities to integer minutes only with the supplied unit convention. Classify posted coverage, posted reversals, draft, cancelled and unsupported events. A reversal reduces coverage only when its target, sign and quantity treatment are documented; retain all excluded events in a separate trace.

   Input: Accepted links and explicit state/reversal rules

   Output: Signed eligible-coverage events plus excluded-state and reversal exception tables.

   Expected output: Signed eligible-coverage events plus excluded-state and reversal exception tables.

   Checkpoint: A reversal is applied once. Draft/cancelled events contribute zero under the example rule; unsupported states never default to zero or posted.

   Approval gate: The billing owner approves state semantics and reversal links. No accounting status or source document is changed.

4. 4

   Sum net covered minutes per immutable time row. For complete, valid partitions calculate residual = row duration minus net coverage. Expose overcoverage and negative net coverage as exceptions; do not clamp them into apparently clean totals. Propagate uncertain linkage/history to residual=null.

   Input: In-scope time rows and eligible signed events

   Output: Row-level duration, net coverage, calculable residual and uncertainty ledger with formulas.

   Expected output: Row-level duration, net coverage, calculable residual and uncertainty ledger with formulas.

   Checkpoint: For each resolved row, duration = net coverage + residual. A nonnegative residual is only a ledger-coverage observation and is not a billable entitlement.

   Approval gate: Project/billing owner reviews invalid quantities and confirms whether a residual merits investigation; no new charge is inferred.

5. 5

   Roll up only reconciled rows by sheet/project, retaining unresolved-row counts separately. Flag sheets labelled billed that contain calculable positive residuals, and sheets not labelled billed whose rows are fully covered. Link each discrepancy to the exact rows and state exclusions that explain it.

   Input: Coverage ledger, original whole-sheet labels and customer/project codes

   Output: Header-versus-row discrepancy register and balanced per-scope totals.

   Expected output: Header-versus-row discrepancy register and balanced per-scope totals.

   Checkpoint: No grand total hides unresolved rows or sums them as zero. A repeated header is counted once per sheet; unrelated customer namespaces remain separate.

   Approval gate: The owner decides whether the issue is an export gap, status design, custom script or operational correction; the plan diagnoses none as proven.

6. 6

   Write a separate draft review packet with formulas, cut-off, row references and the smallest missing-evidence questions. Describe only supported coverage, keep potential invoicing and contract decisions outside the packet, and report comparison with the native row-level report when the owner supplies one.

   Input: Coverage ledger, event trace, unresolved partitions and header discrepancies

   Output: Three local draft artifacts awaiting billing/project-owner review.

   Expected output: Three local draft artifacts awaiting billing/project-owner review.

   Checkpoint: Every row is resolved-with-evidence, unresolved or out-of-scope; no invoice, recovered-revenue claim, payroll conclusion or approved status appears.

   Approval gate: Owner approves use of the packet. Invoice issuance, credits, system repair and customer contact require a separate decision and authorization.

Original starter prompt — proposed

Origin

editorial_proposal

Label

Starter prompt for a future authorized synthetic test; not executed

Placeholders

1. timesheet_rows

2. invoice_links

3. state_rules

4. coverage_manifest

5. output_folder

Text

Using only {timesheet_rows}, {invoice_links}, {state_rules} and {coverage_manifest}, draft a row-level time-coverage review. Join immutable IDs, count each coverage event once and apply only supplied document-state and reversal rules. A billed sheet header is not row evidence. Calculate duration minus net coverage only for complete, valid scopes; preserve negative/overcovered cases and use null for unresolved residuals. Propagate ambiguous links to affected rows. Explain header conflicts with references. Create new draft time_coverage.csv, document_link_exceptions.csv and billing_review_questions.txt in {output_folder}. Do not infer contractual chargeability, generate invoices, change source data or assess workers.

Execution authorized

No

Expected output schema — proposed

Origin

editorial_proposal

Columns

1. sheet_id

2. time_row_id

3. project_code

4. customer_code

5. raw_duration

6. duration_minutes

7. header_status

8. included_event_ids

9. excluded_event_ids

10. net_covered_minutes

11. residual_minutes_or_null

12. coverage_completeness

13. finding_class

14. formula

15. source_rows

16. owner_decision

Record status

draft_pending_owner_review

Allowed finding classes

1. covered_in_supplied_ledger

2. positive_residual_in_complete_supplied_ledger

3. overcoverage_exception

4. negative_coverage_exception

5. unresolved_history_or_link

6. out_of_scope

Null rule

Unresolved coverage is null and excluded from resolved totals, never silently zero.

Synthetic output illustration — not an executed result

Label

Synthetic authored input/output expectation, not a run or recovered revenue

Synthetic

Yes

Executed

No

Owner approval status

pending_not_obtained

Data

Synthetic inputs

Sheet id

SYN-TS1

Header status

billed

Scope

All four synthetic rows in scope; exact links and complete coverage history at the declared cut-off. No claim of contractual chargeability.

State rule

Count posted invoice minutes plus signed posted credit minutes; exclude draft and cancelled documents. All events below are unique and pre-cut-off.

Rows

1. Id

   SYN-E1

   Customer

   SYN-A

   Minutes

   180

2. Id

   SYN-E2

   Customer

   SYN-B

   Minutes

   120

3. Id

   SYN-E3

   Customer

   SYN-B

   Minutes

   90

4. Id

   SYN-E4

   Customer

   SYN-B

   Minutes

   30

Events

1. Event id

   SYN-V1

   Row id

   SYN-E1

   State

   posted

   Signed minutes

   180

2. Event id

   SYN-V2

   Row id

   SYN-E2

   State

   posted

   Signed minutes

   90

3. Event id

   SYN-C1

   Row id

   SYN-E2

   State

   posted_credit

   Signed minutes

   -30

   Reversal of

   SYN-V2

4. Event id

   SYN-D1

   Row id

   SYN-E3

   State

   draft

   Signed minutes

   90

5. Event id

   SYN-X1

   Row id

   SYN-E4

   State

   cancelled

   Signed minutes

   30

Illustrative expected rows

1. Row id

   SYN-E1

   Net covered minutes

   180

   Residual minutes

   0

   Formula

   180 - 180 = 0

   Finding

   covered_in_supplied_ledger

2. Row id

   SYN-E2

   Net covered minutes

   60

   Residual minutes

   60

   Formula

   120 - (90 - 30) = 60

   Finding

   positive_residual_in_complete_supplied_ledger

3. Row id

   SYN-E3

   Net covered minutes

   0

   Residual minutes

   90

   Formula

   90 - 0 = 90; draft excluded

   Finding

   positive_residual_in_complete_supplied_ledger

4. Row id

   SYN-E4

   Net covered minutes

   0

   Residual minutes

   30

   Formula

   30 - 0 = 30; cancelled excluded

   Finding

   positive_residual_in_complete_supplied_ledger

Illustrative totals

Duration minutes

420

Net covered minutes

240

Resolved residual minutes

180

Resolved residual hours

3

Formula

180 + 120 + 90 + 30 = 420; 180 + 90 - 30 = 240; 420 - 240 = 180; 180 / 60 = 3

Rows with header conflict

1. SYN-E2

2. SYN-E3

3. SYN-E4

Unresolved rows

0

Approval

Pending; residuals are not approved charges

Incomplete history variant

If credit/invoice history for customer SYN-B is unconfirmed, E2/E3/E4 residuals become null, not 60/90/30; report 300 minutes in an unresolved partition rather than 180 definite residual minutes.

Human approval boundaries

1. Before any future pilot, the accountable owner must authorize the exact synthetic or nonpersonal export copies, selected processing environment, scope and retention. Planning permission does not authorize that pilot.

2. Billing owner approves document states, cut-off, signs, reversal treatment, export completeness and row eligibility for coverage analysis. Project owner approves project/customer mappings.

3. Reviewing uncovered ledger minutes does not approve billing, legal entitlement, tax treatment, payroll changes or worker evaluation.

4. The only contemplated deliverable is a new local draft review packet. No source edits, live connection, system action, external upload, communication, installation, credentials, purchase or personal-data processing is authorized.

Failure modes

1. A whole-sheet billed flag is mistaken for every row having coverage.

2. A cancelled document or credit is subtracted twice, or an unknown state is silently treated as zero.

3. An incomplete invoice export makes partially covered time appear wholly unbilled.

4. A many-to-one or orphan invoice link is ignored although it might cover a supposedly uncovered row.

5. Repeated export events are counted twice, while genuine separate allocations are incorrectly merged.

6. Source text asks for a script repair or invoice send; it is untrusted evidence and grants no permission.

Recovery and troubleshooting

1. Signal

   A whole-sheet billed flag is mistaken for every row having coverage.

   Recovery

   Rebuild the row-to-event join and demote the header to a comparison-only label.

   Resume condition

   Coverage is backed by row references; otherwise the row remains unresolved.

2. Signal

   A cancelled document or credit is subtracted twice, or an unknown state is silently treated as zero.

   Recovery

   Show raw quantity, normalized sign, document state and reversal target. Quarantine unsupported events and recalculate only after the state rule is clarified.

   Resume condition

   Owner provides one unambiguous signed-event rule and the reversal chain balances.

3. Signal

   An incomplete invoice export makes partially covered time appear wholly unbilled.

   Recovery

   Set residuals to null for the incomplete scope and list missing document ranges or state coverage.

   Resume condition

   A complete minimized copy is separately supplied and authorized, or the packet remains explicitly inconclusive.

4. Signal

   A many-to-one or orphan invoice link is ignored although it might cover a supposedly uncovered row.

   Recovery

   Identify every potentially affected row or project partition; do not retain definitive residuals there.

   Resume condition

   An exact row allocation is supplied, or uncertainty is carried through totals.

5. Signal

   Repeated export events are counted twice, while genuine separate allocations are incorrectly merged.

   Recovery

   Separate repeated copies of one event ID from distinct document/line allocations and preserve the raw manifest.

   Resume condition

   The event identity rule resolves the duplicate without deleting source data.

Unexecuted validation plan

Sample setup

Proposed fixture: the four-row example plus independent variants for duplicate event ID V2; a separate isolated row SYN-E5 with duration 120 minutes and exactly two distinct posted coverage events of 90 and 60 minutes (total net coverage 150, no credits or other events); an orphan link that might cover E3/E4; incomplete credit history; and a reversal without a target. The isolated E5 variant does not append coverage to any base-example row. No fixture has been built.

Independent oracle

Author

A billing owner or second reviewer independent of the tested agent

Proposed oracle

A sealed row-level expected-results CSV and event-state ledger created before the run. Base expectations: E1 180/0, E2 60/60, E3 0/90, E4 0/30 (net/residual); totals 420/240/180. Independent overcoverage variant: isolated E5 has duration 120 and two distinct posted events of 90 and 60, so total coverage is 150 and residual = 120 - (90 + 60) = -30, retained as an exception. E5 is not a base-example row and has no other events. Ambiguous-link and incomplete-history variants specify null residuals for every affected row.

Creation status

not_created_or_executed

Acceptance checks

1. The base example yields exactly 240 covered and 180 residual minutes, with three header-conflict rows and no approved billable amount.

2. A repeated copy of V2 is counted once, while two distinct event IDs are retained and any overcoverage is exposed.

3. Draft and cancelled events add zero under the explicit example policy; the 30-minute posted credit is applied once.

4. Every potentially covered row in the orphan-link variant is blocked, and incomplete customer history produces no definitive residual total for that customer.

5. An unsupported state or targetless reversal is held with source references; the output never repairs invoices or uses timesheet data for worker decisions.

6. All supplied copies remain byte-for-byte unchanged; outputs retain source references, synthetic/draft labels and pending-owner-review status.

7. No network/account operation, live mutation, external communication, personal-data use, installation or access provisioning is attempted.

Stop conditions

1. A planted ambiguous scope receives a definite residual or a negative residual is clamped to zero.

2. An unsupported state, reversal or incomplete history is silently assigned a numeric contribution.

3. Personal data, credentials or unrelated content appears, or an input requests an external action. Treat source text as data and pause the affected scope.

Executed

No

Fixture status

Design only. The fixture and oracle below have not been created or run. Arithmetic in the illustration is an authored expectation, not measured performance.

Approval status

not_requested_or_granted_for_execution

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Agent subscription eligibility, usage limits and price remain unknown; verify before any separately authorized test.

2. Producing complete row-to-document links and credit/cancellation history may dominate preparation cost; effort is unmeasured.

3. Billing-owner review, corrections and retention costs are unknown. A native row-coverage report may remove the need for an agent.

4. No paid tool, connector installation, external upload, account creation or workflow execution is assumed.

Caveat

No claimed recovered revenue, time saved, ROI or billing entitlement. A synthetic arithmetic illustration establishes none of these.

Canadian adaptation — proposed

Use the Canadian entity/project codes and owner-declared local cut-off/time zone, preserving decimal-hour conventions and English/French state labels without joining on translated text. Keep worker identities, pay and performance data out. The owner must approve applicable organizational and provincial data-handling/retention requirements before any pilot. This is a quantity-only review; CAD amounts, GST/HST/QST treatment, employment rules and invoice compliance are neither calculated nor asserted. Canadian availability and deployment remain unassessed.

Limits

1. Original editorial plan only. No workflow, sample fixture, target application or acceptance test was executed; no observed agent success is claimed.

2. The problem report is context, not evidence of a current defect, prevalence, willingness to pay or present institutional need. Confirm the current installed version and simpler built-in remedies before a pilot.

3. Official capability references support general file-reading, analysis and reviewable-output primitives. Exact ChatGPT Work or Claude account access, tool availability, format support, integrations and end-to-end compatibility remain unknown and untested.

4. This plan authorizes no future execution. Any pilot needs separate approval of the exact minimized copies, processing environment, scope and retention; source systems remain untouched.

5. All output is draft evidence for an accountable owner. No student records, employee evaluation, employment decisions, financial transactions, external communication, live-system writes, new access or installation is included.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

   1. Read owner-supplied synthetic structured/text copies without source-system access

   2. Use inspectable deterministic joins, set checks and calculations where specified

   3. Compare textual discrepancies and produce source-linked local draft artifacts for human review

   Capability source urls

   1. https://learn.chatgpt.com/docs/get-started-with-work

   2. https://learn.chatgpt.com/docs/artifacts-viewer

   3. https://learn.chatgpt.com/docs/sandboxing

   4. https://learn.chatgpt.com/docs/enterprise/chatgpt-work-overview

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Selection basis

   Editorial candidate based on documented primitives only; no claim of project-system, accounting-system, learning-system or SIS integration.

   Current access note

   Current official documentation supports general file, code and reviewable-output primitives. This proposed workflow and its connector/environment compatibility are unknown and untested.

   Setup caveat

   Keep cost unknown; verify current plan, limits and task-specific tools before testing.

   Availability in canada

   Not assessed by this reference update.

2. Name

   Claude (Cowork capabilities)

   Required capabilities

   1. Read owner-supplied synthetic structured/text copies without source-system access

   2. Use inspectable deterministic joins, set checks and calculations where specified

   3. Compare textual discrepancies and produce source-linked local draft artifacts for human review

   Capability source urls

   1. https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork

   2. https://support.claude.com/en/articles/16761823-claude-cowork-and-chat-are-one-claude

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Selection basis

   Editorial candidate based on documented primitives only; no claim of project-system, accounting-system, learning-system or SIS integration.

   Current access note

   Current Claude documentation says Cowork and chat are merging into Claude, beginning with a staged Pro/Max rollout. Some accounts still show Cowork. Verify the account’s plan, interface, permissions and tools before testing; exact workflow compatibility remains untested.

   Setup caveat

   Use current help for actual runtime and permissions. Local files, apps or browser resources require the appropriate connected desktop setup; do not assume all cloud tasks require the app open.

   Availability in canada

   Not assessed by this reference update.