Explain a zero-cash remittance without treating claims as credits

Before a pilot — required, unexecuted

1. A separately authorized pilot must use an independently prepared answer key, not the model’s own output as its oracle.

2. Verify the reported issue on the exact target product version and prefer a sufficient native feature or simpler method.

Setup requirements

1. The accountant defines cash, approved credit and customer-asserted deduction as separate categories.

2. Require exact invoice/credit identifiers, party and currency scope, remaining balances and snapshot authority.

3. The dispute owner supplies evidence status; the model cannot infer entitlement from a remittance reason.

4. Verify the existing product workflow and current unresolved need before any pilot; ignore unverified forum import instructions.

5. Require stable credit_allocation_id and claim_allocation_id linking source remittance lines to exact invoices. Store per-credit and per-claim totals separately from invoice totals.

6. Owner must approve any split of one credit or claim across invoices. If aggregate requested credit exceeds the available balance, hold every competing allocation; never award capacity by input order.

Inputs and access

1. Name

   remittance_copy.txt

   Source or owner

   AR owner

   Scope

   Synthetic remittance_id and line_id, exact party/currency, invoice_id, credit_id, claim_id, requested amounts and evidence spans; one component per source allocation row. Preserve repeated appearances.

   Sensitivity

   Synthetic fixture only; no real personal, customer financial or employee data in this design.

   Permission needed

   A future pilot requires exact owner-approved minimized copies, approved processing environment, retention and recipients; no pilot authorized here.

2. Name

   open_invoice_snapshot.csv

   Source or owner

   AR owner

   Scope

   Synthetic invoice IDs, party/currency tokens, open amounts and snapshot time.

   Sensitivity

   Synthetic fixture only; no real personal, customer financial or employee data in this design.

   Permission needed

   A future pilot requires exact owner-approved minimized copies, approved processing environment, retention and recipients; no pilot authorized here.

3. Name

   credit_snapshot.csv

   Source or owner

   AR owner

   Scope

   Synthetic credit_id scoped by legal entity, party and currency; original amount, historically used amount, authoritative remaining_available_amount, snapshot time, status and existing allocation IDs. State whether remaining balance already nets historic use; do not subtract historic use twice.

   Sensitivity

   Synthetic fixture only; no real personal, customer financial or employee data in this design.

   Permission needed

   A future pilot requires exact owner-approved minimized copies, approved processing environment, retention and recipients; no pilot authorized here.

4. Name

   claim_evidence_index.csv

   Source or owner

   Dispute owner

   Scope

   Synthetic claim_id scoped by legal entity, party and currency, asserted total, permitted invoice references, evidence references and owner-supplied status. Repeated appearances are retained; legitimate claim splits need explicit owner allocation evidence.

   Sensitivity

   Synthetic fixture only; no real personal, customer financial or employee data in this design.

   Permission needed

   A future pilot requires exact owner-approved minimized copies, approved processing environment, retention and recipients; no pilot authorized here.

5. Name

   review_rules.txt

   Source or owner

   Accountant

   Scope

   Signed-amount convention, currency policy, authoritative snapshots, duplicate handling and export-completeness scope. Define duplicate versus split-claim handling and whether availability is net of prior allocations. A snapshot mismatch blocks aggregation.

   Sensitivity

   Synthetic fixture only; no real personal, customer financial or employee data in this design.

   Permission needed

   A future pilot requires exact owner-approved minimized copies, approved processing environment, retention and recipients; no pilot authorized here.

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 remittance may purport to cover invoices entirely with credits and disputed deductions. An AR clerk needs a complete line-level explanation while keeping a customer claim separate from an approved credit or cash receipt.

Suggested task

Build a review-only bridge between referenced invoices, available credit evidence and asserted deduction lines, preserving disputes and unallocated amounts.

What you could produce

An invoice-linked remittance bridge, credit-availability exceptions and deduction-evidence queue; no settlement, journal or claim decision.

Why an agent / simpler alternative

An agent may parse mixed narrative remittances and connect claim explanations to supplied evidence. Arithmetic, uniqueness and allocation checks must be deterministic. If a native deduction workbench or a structured remittance import already gives the required evidence view, use it. No agent advantage is claimed for a clean table that a spreadsheet can reconcile.

When this work comes up

Role

Accounts-receivable clerk

Trigger

A remittance claims invoices are covered without a cash receipt.

Finished output

An invoice-linked remittance bridge, credit-availability exceptions and deduction-evidence queue; no settlement, journal or claim decision.

Human approval

Accountant decides each deduction and any settlement treatment. No posting, importing, write-off, collection or tax conclusion.

Evidence boundary

Problem sources establish human friction; official capability sources establish primitives. Operational steps, synthetic examples and acceptance fixtures are original untested designs.

Proposed steps

1. 1

   Check input scope, currency, amount-sign rules and snapshots. Confirm that the stated cash total is zero without manufacturing a bank transaction to balance it.

   Output: Source and arithmetic convention manifest.

   Expected output: Source and arithmetic convention manifest.

   Checkpoint: No ledger entries or account codes are proposed.

   Approval gate: Accountant approves the classification rules.

2. 2

   Parse every component into typed credit-allocation or claim-allocation rows with stable IDs, remittance/line IDs, invoice_id, credit_id or claim_id, amount and source span. Preserve raw repeated rows and explicitly link suspected duplicates; never silently drop them.

   Output: Evidence-linked remittance line table.

   Expected output: Evidence-linked remittance line table.

   Checkpoint: Unknown references are held, not fuzzy-applied to a similar invoice.

   Approval gate: AR owner resolves unreadable or ambiguous references.

3. 3

   Join exact scoped credit IDs to the authoritative remaining-balance snapshot. Aggregate all proposed uses across every invoice in the packet, compare requested total with remaining availability, and show excess and unrequested balance. Check previous allocations without subtracting them again from an already-net balance. Hold the entire competing group on excess or mismatched snapshots.

   Output: Credit allocation bridge and per-credit conservation table.

   Expected output: Credit allocation bridge and per-credit conservation table.

   Checkpoint: The same credit cannot be spent twice in the draft bridge.

   Approval gate: Accountant confirms authoritative balance scope.

4. 4

   Aggregate typed components by invoice to explain cash, requested credit, asserted deduction and residual. Link every amount back to allocation IDs. Show requested arithmetic separately from amounts that passed identity/availability checks; no allocation becomes authorized merely because it fits.

   Output: Per-invoice explanatory bridge.

   Expected output: Per-invoice explanatory bridge.

   Checkpoint: A balanced row with a disputed deduction remains unresolved.

   Approval gate: Accountant reviews unresolved residuals and claim status.

5. 5

   Build a claim register keyed by scoped claim_id and a claim-to-invoice bridge. Compare raw appearances, unique asserted amount and allocated amount. Flag repeated appearances or unsupported splits without double counting the claim or deciding its validity. Keep unresolved duplicate groups outside final proposed totals and show their raw totals separately.

   Output: Claim register, allocation bridge and evidence questions.

   Expected output: Claim register, allocation bridge and evidence questions.

   Checkpoint: Missing evidence is not evidence against either party.

   Approval gate: Dispute owner makes the substantive claim decision.

6. 6

   Prepare separate non-postable invoice, credit-allocation, credit-summary, claim-register and claim-allocation files with cross-table IDs and owner-decision columns. Check the specified conservation oracle on synthetic data only in a later authorized pilot; do not report it passed now.

   Output: Review-only remittance packet.

   Expected output: Review-only remittance packet.

   Checkpoint: No settlement, import, payment, collection, customer contact or tax conclusion.

   Approval gate: Accountant accepts the packet and separately authorizes any operational step.

Original starter prompt — proposed

Origin

editorial_proposal

Execution authorized

No

Text

Using only {approved_synthetic_inputs} and {owner_rules}, Build a review-only bridge between referenced invoices, available credit evidence and asserted deduction lines, preserving disputes and unallocated amounts. Follow the six-step design. Preserve evidence spans and uncertainty; use inspectable deterministic arithmetic and joins. Write only separate draft review artifacts to {output_folder}. Stop on personal data, missing authority or any required live action. Do not access accounts, mutate source files, send, upload, post, settle, pay or provision access. Preserve credit_id, claim_id, invoice_id and allocation IDs. Reconcile both invoice rows and credit/claim columns. Hold all competing uses if a shared credit is over-allocated; do not subtract historic use twice or silently collapse duplicate claims.

Expected output schema — proposed

Record status

draft_not_postable

Tables

Invoice bridge

Primary key

1. remittance_id

2. legal_entity

3. party_token

4. currency

5. invoice_id

Columns

1. invoice_open_amount

2. cash_amount

3. requested_credit_amount

4. identity_and_balance_checked_credit_amount

5. asserted_deduction_amount

6. requested_arithmetic_residual

7. credit_allocation_ids

8. claim_allocation_ids

9. hold_reason

10. owner_decision

Credit allocations

Primary key

1. credit_allocation_id

Columns

1. remittance_id

2. remittance_line_id

3. legal_entity

4. party_token

5. currency

6. invoice_id

7. credit_id

8. snapshot_id

9. requested_amount

10. source_span

11. duplicate_group_id

12. check_state

13. hold_reason

Credit summary

Primary key

1. legal_entity

2. party_token

3. currency

4. credit_id

5. snapshot_id

Columns

1. original_amount

2. historic_used_amount

3. remaining_available_amount

4. available_is_net_of_history

5. packet_requested_total

6. excess_requested_amount

7. unrequested_available_amount

8. allocation_ids

9. group_hold_reason

Claim register

Primary key

1. legal_entity

2. party_token

3. currency

4. claim_id

Columns

1. asserted_claim_total

2. raw_appearance_total

3. unique_asserted_total

4. proposed_allocation_total

5. appearance_line_ids

6. duplicate_group_id

7. claim_decision_state

8. evidence_links

9. hold_reason

Claim allocations

Primary key

1. claim_allocation_id

Columns

1. remittance_id

2. remittance_line_id

3. legal_entity

4. party_token

5. currency

6. claim_id

7. invoice_id

8. asserted_amount

9. owner_split_reference

10. source_span

11. check_state

12. hold_reason

Synthetic output illustration — not an executed result

Label

Synthetic authored example, not observed output

Synthetic

Yes

Executed

No

Input

Currency

SYN-CUR

Party

SYN-P

Legal entity

SYN-E

Snapshot

SYN-S1

Credits

1. Credit id

   C1

   Available

   700

   Allocations

   A

   700

2. Credit id

   C2

   Available

   450

   Allocations

   B

   500

3. Credit id

   C3

   Available

   600

   Allocations

   C

   350

   D

   300

4. Credit id

   C4

   Original

   1000

   Historic used

   100

   Available

   900

   Available is net of history

   Yes

   Allocations

   E

   400

   F

   300

Invoices

A

1000

B

400

C

350

D

300

E

400

F

300

Claims

1. Claim id

   Q1

   Invoice id

   A

   Asserted total

   300

   Appearance line ids

   1. L1

   2. L2

   Appearance amounts

   1. 300

   2. 300

Cash total

0

Negative controls

1. unknown invoice

2. credit in a different currency

3. missing snapshot

4. same credit ID belonging to another party

Expected

Credit summaries

1. Credit id

   C2

   Requested

   500

   Available

   450

   Excess

   50

   Held invoices

   1. B

2. Credit id

   C3

   Requested

   650

   Available

   600

   Excess

   50

   Held invoices

   1. C

   2. D

3. Credit id

   C4

   Requested

   700

   Available

   900

   Unrequested available

   200

   Allocation ids

   1. C4-E

   2. C4-F

   Authorization

   none

Claim q1

Raw appearance total

600

Unique asserted total

300

Duplicate group

DUP-Q1

Claim decision

pending

Invoice b

Requested credit

500

Open amount

400

Requested arithmetic residual

-100

Invoice over application

100

Settlement authorized

No

Limits

1. Original proposed workflow, not a source-documented agent implementation.

2. No fixture or workflow executed and no acceptance result exists.

3. An individual complaint establishes a reported friction, not frequency, causal harm or current demand.

4. Old issue dates and unknown product builds require target-version and simpler-remedy checks.

5. Account tools, export completeness and end-to-end compatibility remain unverified.

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. Check the shared capability source and the plan requirements.

   Workflow compatibility

   Unknown and untested.

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. Check the shared capability source and the plan requirements.

   Workflow compatibility

   Unknown and untested.

Failure modes

1. An asserted deduction is silently treated as an approved credit.

2. One credit reference is reused across invoices beyond its remaining balance.

3. Similar invoice numbers or mixed currencies produce a false exact balance.

4. Invoice-level totals hide overuse of one shared credit or reuse of a claim ID.

5. Net available credit is reduced twice by historical allocations.

Recovery and troubleshooting

1. Signal

   An asserted deduction is silently treated as an approved credit.

   Recovery

   Restore separate claim and approved-credit categories and re-open the decision field.

   Resume condition

   Dispute owner supplies an explicit decision, outside this design.

2. Signal

   One credit reference is reused across invoices beyond its remaining balance.

   Recovery

   Hold all competing uses and show the excess against the authoritative snapshot.

   Resume condition

   Accountant supplies corrected available balance/allocation evidence.

3. Signal

   Similar invoice numbers or mixed currencies produce a false exact balance.

   Recovery

   Partition by exact party/currency and quarantine uncertain identity without conversion.

   Resume condition

   Owner confirms identifiers and any approved currency basis.

4. Signal

   Invoice-level totals hide overuse of one shared credit or reuse of a claim ID.

   Recovery

   Rebuild typed allocation bridges and group totals with exact scoped IDs; hold the affected credit/claim group.

   Resume condition

   Owner supplies authoritative allocation and duplicate-resolution evidence.

5. Signal

   Net available credit is reduced twice by historical allocations.

   Recovery

   Restore the net-balance convention and recompute from the authoritative snapshot.

   Resume condition

   Accountant confirms availability definition and snapshot.

Unexecuted validation plan

Sample setup

Currency

SYN-CUR

Party

SYN-P

Legal entity

SYN-E

Snapshot

SYN-S1

Credits

1. Credit id

   C1

   Available

   700

   Allocations

   A

   700

2. Credit id

   C2

   Available

   450

   Allocations

   B

   500

3. Credit id

   C3

   Available

   600

   Allocations

   C

   350

   D

   300

4. Credit id

   C4

   Original

   1000

   Historic used

   100

   Available

   900

   Available is net of history

   Yes

   Allocations

   E

   400

   F

   300

Invoices

A

1000

B

400

C

350

D

300

E

400

F

300

Claims

1. Claim id

   Q1

   Invoice id

   A

   Asserted total

   300

   Appearance line ids

   1. L1

   2. L2

   Appearance amounts

   1. 300

   2. 300

Cash total

0

Negative controls

1. unknown invoice

2. credit in a different currency

3. missing snapshot

4. same credit ID belonging to another party

Acceptance checks

1. C1 requested700 equals available700. A requested residual is0 after a single unique Q1 amount300, yet the repeated Q1 appearances and disputed status keep A pending; do not report paid.

2. C2 explicitly has450 available against500 requested: credit excess50 and invoice B over-application100 are separately visible.

3. Shared C3 requested650 across C and D exceeds600 by50. Both allocation rows are held; do not choose the first invoice or silently reduce one allocation.

4. Shared C4 requested700 across E and F is within authoritative net available900, leaving200. Historic use100 is not subtracted again. E/F row sums and C4 column sum reconcile.

5. Q1 preserves L1 and L2, raw appearance total600, unique asserted total300 and unresolved duplicate group. No approved claim or silent deletion is inferred.

6. Every invoice amount links to specific credit/claim allocation IDs; every summary total can be recomputed from those rows within exact legal entity/party/currency/snapshot scope.

7. Unknown references, mismatched currencies or missing availability remain unresolved. No source mutation, posting file, settlement, payment, collection or claim decision.

Stop conditions

1. Missing identifiers, authority, completeness, sign conventions or net-balance definition.

2. Requested external action or substantive accounting/claim determination.

3. Unexpected real sensitive data.

Executed

No

Fixture status

Designed only; no workflow or oracle execution.

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.

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.