Separate deal totals from period-specific sales measures

Setup requirements

1. Choose and label the metric before any arithmetic. Scheduled payment is neither collected cash nor accounting revenue.

2. Require explicit schedules; never divide a contract total evenly merely because it spans several years.

3. Reconcile each currency separately unless the owner supplies dated rates and an approved reporting basis.

4. Agree this bounded synthetic scope and confirm a real unresolved need before any implementation pilot. The written design does not authorize executing it.

Inputs and access

1. Name

   deal_snapshot.json

   Source or owner

   Sales operations

   Scope

   Synthetic closed deal IDs, total amount, close date, currency and existing report value.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

2. Name

   approved_payment_schedules.txt

   Source or owner

   Account owner

   Scope

   Synthetic contract schedule excerpts, due dates, explicit amounts and linked deal IDs.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

3. Name

   report_definition.json

   Source or owner

   Finance and sales owner

   Scope

   Approved definitions for bookings and scheduled payments, calendar, cutoff, cancellation handling and currency policy.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

4. Name

   dashboard_export.json

   Source or owner

   Report owner

   Scope

   Synthetic period totals and deal-level detail with snapshot and filter scope.

   Sensitivity

   Synthetic fixture only. A real-data pilot requires a separate minimized scope and approved handling.

   Permission needed

   Owner approval of exact data, processing environment, retention and recipients before a pilot. No pilot is authorized by this plan.

Human approval boundaries

1. Before a pilot, the accountable owner approves exact synthetic/minimized copies, processing environment, retention and allowed recipients.

2. Owner validates identity mappings, authority, status definitions and all unresolved evidence.

3. Any source mutation, account access, upload, external communication, commercial commitment, payment or changed permission requires separate appropriate authorization.

The problem

A report can mix total multi-year contract value with payments assigned to individual periods. The owner needs a traceable explanation of the difference before trusting a sales dashboard.

Suggested task

Build separate owner-defined bookings and scheduled-payment views and reconcile their difference to source deal records.

What you could produce

A period-by-deal bridge with explicit metric definitions, timing differences and unresolved schedules; no accounting revenue-recognition conclusion.

Why an agent / simpler alternative

An agent can reconcile prose schedules and conflicting dashboard labels. The arithmetic and grouping should be formula-based. A clean normalized deal schedule only needs a query or spreadsheet; the agent is justified only by document interpretation and exception explanation.

When this work comes up

Role

Sales operations analyst

Trigger

A dashboard period total differs from the deal register after multi-year deals are included.

Human approval

Owner reviews scope, rules, identities and findings; operating decisions remain separately authorized.

Finished output

A period-by-deal bridge with explicit metric definitions, timing differences and unresolved schedules; no accounting revenue-recognition conclusion.

Proposed evaluation scope — no pilot authorized

Scope

At most 20 synthetic deals, three calendar years and two currencies kept separate.

Limit origin

Original editorial evaluation bound, not a verified tool limit.

Overflow action

Stop and request owner-approved partitioning; no silent truncation.

Pilot authorized

No

Evidence boundary

Source facts describe human friction; O*NET describes duties; shared official documentation supports file primitives. The six-step workflow, safeguards, numerical fixture and outputs are original proposed designs.

Proposed steps

1. 1

   Record the report filters, snapshots and owner-approved measure definitions.

   Output: Metric and scope contract.

   Expected output: Metric and scope contract.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner approves exact inputs and rule scope before any pilot.

2. 2

   Extract schedule events with exact deal linkage, amount, date and evidence; distinguish payment due from payment received.

   Output: Scheduled-event ledger.

   Expected output: Scheduled-event ledger.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner resolves ambiguous meaning, identity or authority before affected rows advance.

3. 3

   Check each schedule against its contract total and identify missing, duplicate or contradictory events.

   Output: Completeness and conservation exceptions.

   Expected output: Completeness and conservation exceptions.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner resolves ambiguous meaning, identity or authority before affected rows advance.

4. 4

   Create separate bookings-at-close and scheduled-payment-by-period tables using the supplied calendar.

   Output: Two labelled metric views.

   Expected output: Two labelled metric views.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner resolves ambiguous meaning, identity or authority before affected rows advance.

5. 5

   Bridge the difference by deal and period; isolate timing effects from missing data, filters or duplicated records.

   Output: Explained dashboard variance.

   Expected output: Explained dashboard variance.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner reviews draft findings; no operational action authorized.

6. 6

   Package formulas, unresolved cases and the acceptance specification for finance and sales review.

   Output: Review-only report pack.

   Expected output: Review-only report pack.

   Checkpoint: Retain source IDs/spans and explicit unknown states. No source writes or external action.

   Approval gate: Owner accepts the review artifact; any live change or communication needs separate approval.

Original starter prompt — proposed

Origin

editorial_proposal

Execution authorized

No

Text

Using only {approved_synthetic_inputs} and {owner_rules}, Build separate owner-defined bookings and scheduled-payment views and reconcile their difference to source deal records. Follow the six-step design. Preserve exact identities, source citations and uncertainty; make calculations inspectable. Write only separate review drafts to {approved_output_folder}. Do not guess missing facts, alter sources, access accounts, send, upload, buy, post, settle, make personnel decisions or claim the fixture passed.

Expected output schema — proposed

Primary key

1. metric_id

2. currency

3. deal_id

4. period_id

5. event_id

Columns

1. source_amount

2. period_amount

3. report_amount

4. variance_reason

5. schedule_complete

6. definition_version

7. source_spans

8. hold_reason

Record status

draft_review_only

Common provenance columns

1. input_snapshot_id

2. rule_version

3. source_document_id

4. source_row_or_span

5. reviewer_decision

Unknown value policy

Unknown numeric values remain null, never zero. Preserve raw rows and typed relation/allocation IDs; unresolved rows do not silently enter approved totals.

Synthetic output illustration — not an executed result

Label

Synthetic authored example, not observed output

Synthetic

Yes

Executed

No

Input

D1 total

120

D1 schedule

1. 20

2. 40

3. 60

D2 2026

30

Expected

Bookings 2026

150

Scheduled payments 2026

50

Timing difference

100

Actual cash received

Not specified.

Recognized revenue

Not specified.

Limits

1. Original proposed and untested design; no source documents this complete agent workflow.

2. A reported problem is not proof of prevalence, willingness to pay, harm magnitude or current demand.

3. Historical product reports require current-installation checks; a current capability document only establishes general primitives.

4. Native reports or a deterministic script may be simpler. Exports, identity mappings, context size, privacy controls and actual tool compatibility remain untested.

5. Numerical fixtures are synthetic and have not been executed. Owner review is necessary; no time saving, cost saving or revenue outcome is asserted.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

   1. Assess this plan’s input, operation and output requirements before selecting an account.

   Capability source urls

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

   Selection basis

   Editorial candidate only. Shared source facts are general primitives; this plan remains unexecuted.

   Workflow compatibility

   BotCurrent has not tested this workflow.

2. Name

   Claude

   Required capabilities

   1. Assess this plan’s input, operation and output requirements before selecting an account.

   Capability source urls

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

   Selection basis

   Editorial candidate only. Shared source facts are general primitives; this plan remains unexecuted.

   Workflow compatibility

   BotCurrent has not tested this workflow.

Failure modes

1. A total contract amount is counted again alongside its schedule events.

2. Even annual allocation is invented for an irregular contract.

3. Payment dates are labelled as recognized revenue or actual collections.

Recovery and troubleshooting

1. Signal

   A total contract amount is counted again alongside its schedule events.

   Recovery

   Separate measure IDs and reconcile each independently; forbid summing across metric types.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or approved interpretation; otherwise keep the affected result unresolved.

2. Signal

   Even annual allocation is invented for an irregular contract.

   Recovery

   Hold the missing schedule and request authoritative dates and amounts.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or approved interpretation; otherwise keep the affected result unresolved.

3. Signal

   Payment dates are labelled as recognized revenue or actual collections.

   Recovery

   Rename columns to the approved measure and remove unsupported collection/recognition claims.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or approved interpretation; otherwise keep the affected result unresolved.

Unexecuted validation plan

Sample setup

Deal D1 closes in 2026 for 120 with approved scheduled payments 20 in 2026, 40 in 2027 and 60 in 2028. D2 is a one-time 30 deal with payment scheduled in 2026. The dashboard labels 150 as 2026 payments. Add D3 total 90 with no schedule and one duplicated D1 event.

Acceptance checks

1. 2026 bookings are 150 for D1/D2; scheduled payments are 50, with 100 explained by later scheduled periods.

2. D1 schedule sums 120 across its three events, with no straight-line 40 substitution.

3. D3 remains schedule-unknown and is not filled with zero or equal annual shares.

4. A duplicate event is retained in an exception group and cannot inflate the accepted schedule total.

5. No accounting recognition, cash collection or performance-pay conclusion is generated.

6. Every conclusion traces to approved source rows or an explicitly labelled owner rule; rerunning the same frozen input must not change identities or totals.

7. All source copies remain unchanged. Any duplicate, missing key, stale snapshot or conflicting authority is held visibly.

Stop conditions

1. Input scope, required identity or calculation policy is missing.

2. Unexpected real sensitive/personal data is supplied before handling approval.

3. The requested output would require live account access, external upload/send, accounting posting, purchase, access change or irreversible action.

Executed

No

Fixture status

Designed only; no acceptance fixture or workflow executed.

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Plan access, model usage, tool runtime and storage costs unknown.

2. Export preparation, evidence cleanup, review and correction effort unmeasured.

3. No native integration, paid service, new account or software installation assumed.

4. Case-specific effort is unknown: source extraction, identity repair, owner-rule preparation, fixture design and review may dominate model cost.

Caveat

No measured time saving, current demand, ROI or price claim. Compare the simpler remedy first.

Canadian adaptation — proposed

Verify local privacy and organizational record-handling requirements before any real-data pilot; preserve original currency, business calendars and time zones. No Canadian deployment or compliance claim.