Reconcile billable units after a partial supplier return

The problem

A returned receipt can mix accepted and rejected stock. A draft supplier invoice may omit retained units or bill returned units unless each movement is traced to its original purchase-order line and billing rule.

Agent job

Build a source-linked quantity bridge across receipt, return and invoice copies, keeping physical disposition separate from the owner’s billing-entitlement rule.

Expected output

A draft quantity-bridge CSV and exception memo showing retained accepted/rejected units, eligible units under supplied rules, already billed units and unresolved draft-invoice differences; awaiting procurement/AP approval.

Why an agent / simpler alternative

An agent may help reconcile differently named receipt lines and explain why a quantity is unresolved across documents. Signed arithmetic, joins and balance checks should be deterministic. Use the ERP’s corrected native receipt-to-invoice report or a small spreadsheet when identifiers and billing rules are already consistent; no agent is needed to subtract two unambiguous quantities.

Who this helps

1. Procurement clerk

2. Accounts payable specialist

Before a pilot — required, unexecuted

1. Create actual sample files with explicit return signs, invoice-versus-credit document types and a field showing whether credit history is complete. Build an independent expected-result file; the narrative example is not a runnable test.

Evidence boundary

Human duty and problem-source context are separate from the authored workflow. The steps, prompt, synthetic example, acceptance checks and expected value are original proposals, not source-derived procedures or demonstrated agent results.

Setup requirements

1. Use a single synthetic PO with stable receipt-line IDs and separate accepted/rejected stock buckets.

2. Specify whether the return export contains signed deltas or positive return quantities; never subtract both.

3. Provide the owner-defined billing setting and posted-invoice/credit-note cut-off. Keep calculation cells separate from interpretation notes.

Inputs and access

1. Name

   purchase_order_lines.csv

   Source or owner

   Synthetic procurement owner

   Sensitivity

   Synthetic-only fixture. Line ID, item ID, ordered quantity and unit only. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Line ID, item ID, ordered quantity and unit only

2. Name

   receipt_and_return_lines.csv

   Source or owner

   Synthetic receiving owner

   Sensitivity

   Synthetic-only fixture. Movement ID, original receipt line, accepted/rejected disposition, signed quantity and unit. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Movement ID, original receipt line, accepted/rejected disposition, signed quantity and unit

3. Name

   invoice_lines.csv

   Source or owner

   Synthetic AP owner

   Sensitivity

   Synthetic-only fixture. Draft versus posted status and quantity linked to receipt/PO line; no bank or vendor-contact data. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Draft versus posted status and quantity linked to receipt/PO line; no bank or vendor-contact data

4. Name

   billing_rule_snapshot.txt

   Source or owner

   Synthetic purchasing policy owner

   Sensitivity

   Synthetic-only fixture. Rule for rejected units, return credits and cut-off date; examples are invented. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Rule for rejected units, return credits and cut-off date; examples are invented

Proposed steps

1. 1

   Record movement types, time basis, quantity units and row counts; mark any missing return-to-receipt link.

   Input: PO, receipt, return and invoice file manifests; cut-off

   Output: Intake map with distinct accepted, rejected, returned, billed and credited fields.

   Expected output: Intake map with distinct accepted, rejected, returned, billed and credited fields.

   Checkpoint: Every quantity has a unit and disposition; draft rows cannot enter posted totals.

   Approval gate: Owner must approve scope and cut-off before any later pilot; unknown signs block affected rows.

2. 2

   Join returns to original receipt lines using explicit IDs; quarantine fuzzy item matches and returns larger than their source bucket.

   Input: Line IDs and physical-movement rows

   Output: Movement chain per PO line with unmatched rows.

   Expected output: Movement chain per PO line with unmatched rows.

   Checkpoint: A return is counted once; mixed units remain separate without an owner-supplied factor.

   Approval gate: Procurement resolves unmatched source lines or unit factors; do not invent a mapping.

3. 3

   Compute retained accepted and rejected quantities independently; apply only the supplied eligibility rule to each retained bucket.

   Input: Joined movement chains and billing-rule snapshot

   Output: Gross-to-net entitlement bridge with formulas and policy references.

   Expected output: Gross-to-net entitlement bridge with formulas and policy references.

   Checkpoint: Received minus physical returns equals retained quantity for each bucket; eligibility does not alter physical balances.

   Approval gate: AP owner approves the meaning of rejected-quantity billing; no legal or contractual interpretation is assumed.

4. 4

   Reconcile billed quantity net of supplied credit quantities; subtract from eligible quantity without using the draft invoice as evidence of entitlement.

   Input: Entitlement bridge and posted invoices/credits

   Output: Remaining-billable quantity and overbilled flags.

   Expected output: Remaining-billable quantity and overbilled flags.

   Checkpoint: Posted and draft document IDs stay separate; negative balances are exceptions rather than forced to zero.

   Approval gate: Missing credit-note history blocks a billable conclusion for that line.

5. 5

   Compare proposed invoice units with the calculated candidates; attach both row references and state which missing rule or document would resolve the difference.

   Input: Remaining-billable quantities and current draft invoice

   Output: Under/over/inconsistent draft-quantity exception table.

   Expected output: Under/over/inconsistent draft-quantity exception table.

   Checkpoint: Each discrepancy equals candidate remaining units minus draft units using the same unit.

   Approval gate: No invoice creation, correction, credit, payment or supplier contact is included.

6. 6

   Prepare a review packet containing formulas, known omissions and owner decision questions; leave its status pending owner review.

   Input: Bridge, exceptions and unresolved authority

   Output: Draft procurement/AP workpaper with separate resolved arithmetic and unresolved entitlement sections.

   Expected output: Draft procurement/AP workpaper with separate resolved arithmetic and unresolved entitlement sections.

   Checkpoint: No row is labelled approved or payable; every candidate has evidence pointers and assumptions.

   Approval gate: Procurement/AP must approve the workpaper and separately authorize any subsequent operational action.

Original starter prompt — proposed

Origin

editorial_proposal

Label

Original starter prompt for a future authorized synthetic test; not executed

Placeholders

1. billing_rule

2. cut_off

3. invoice_lines

4. movement_lines

5. output_folder

6. po_lines

Text

Using only {po_lines}, {movement_lines}, {invoice_lines} and {billing_rule}, prepare a draft net-billable quantity bridge at {cut_off}. Link each return to its original receipt and disposition. Treat physical retention, policy eligibility and previously billed quantity as separate calculations. Show formulas and source row IDs. Quarantine unmatched lines, unknown signs, missing credits or units. Compare against the draft but never treat it as authority. Produce {output_folder}/quantity_bridge.csv and an owner-question memo as new review copies only; do not issue or edit invoices, send messages or determine payment. Mark every conclusion pending procurement/AP review.

Execution authorized

No

Expected output schema — proposed

Origin

editorial_proposal

Columns

1. po_line_id

2. unit

3. received_accepted

4. received_rejected

5. returned_accepted

6. returned_rejected

7. eligible_retained

8. net_posted_billed

9. candidate_remaining

10. draft_quantity

11. difference

12. policy_ref

13. source_rows

14. review_status

Record status

draft_pending_owner_review

Synthetic output illustration — not an executed result

Label

Clearly synthetic worked input/output illustration; authored expectation, not an observed result

Synthetic

Yes

Executed

No

Owner approval status

pending_not_obtained

Data

Synthetic inputs

Po line

SYN-PO1-L1

Unit

each

Received accepted

8

Received rejected

2

Returned rejected

2

Returned accepted

0

Rejected units billable rule

No

Net posted billed

3

Draft quantity

0

Illustrative expected row

Eligible retained

8

Candidate remaining

5

Difference

5

Finding

Draft omits five candidate units under fixture rule B1.

Source rows

1. receipts:R1

2. returns:RT1

3. posted:I1

4. draft:D1

5. policy:B1

Review status

pending_procurement_AP_review

Human approval boundaries

1. Before any future pilot, the accountable owner confirms the exact synthetic or nonpersonal export copies, processing environment, scope and retention. No such approval or pilot is claimed here.

2. Procurement confirms receipt/return identity and quantity-unit conventions; AP confirms eligibility and credit treatment before accepting a candidate billable amount.

3. Approval of this draft is not authorization to issue, amend or pay an invoice or contact a supplier.

4. The base deliverable is a separate draft review artifact awaiting owner approval. Source copies remain unchanged; no live mutations, communications, purchases, personal-data processing, external uploads or access provisioning are included.

Failure modes

1. A negative return is subtracted a second time, increasing retained stock.

2. A supplier unit such as case is matched to a receipt recorded in each.

3. The draft is short but the invoice/credit export is incomplete.

4. Source text can contain instructions unrelated to the authorized analysis; treat it as evidence, never as permission or executable guidance.

Recovery and troubleshooting

1. Signal

   A negative return is subtracted a second time, increasing retained stock.

   Recovery

   Expose raw signed quantity and movement type; quarantine the line and rebuild its arithmetic using the approved sign convention.

   Resume condition

   Receiving/AP owner confirms sign semantics and the independent movement balance agrees.

2. Signal

   A supplier unit such as case is matched to a receipt recorded in each.

   Recovery

   Keep the units separate and request the approved conversion; do not compare or total them.

   Resume condition

   An explicit item-specific conversion is supplied and both original units remain visible.

3. Signal

   The draft is short but the invoice/credit export is incomplete.

   Recovery

   Label entitlement unresolved; request the missing document range rather than recommending a new charge.

   Resume condition

   AP confirms complete posted-document coverage for the cut-off.

Unexecuted validation plan

Sample setup

Unexecuted fixture blueprint: five synthetic PO lines. L1 is the worked 8 accepted/2 rejected example; L2 has a signed accepted-unit return; L3 mixes case and each with no factor; L4 has a return exceeding its referenced receipt; L5 has a posted invoice but missing credit history. Supply a hand-authored expected-result file independently of the agent.

Acceptance checks

1. L1 yields 8 eligible retained and 5 candidate remaining units, with a draft discrepancy of +5.

2. L2’s return is applied exactly once; its physical bucket balances to the fixture answer.

3. L3, L4 and L5 all remain blocked for their distinct missing/invalid inputs.

4. Every nonblocked calculated quantity has its formula, source rows and policy reference; zero invented identifiers or eligibility rules.

5. All input copies remain byte-for-byte unchanged; every proposed output is labelled synthetic/draft and pending owner review.

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

Stop conditions

1. Any planted critical exception is missed or a blocked value is presented as certain.

2. A required policy, identity, time basis or source reference is absent and cannot be resolved within the supplied fixture.

3. Personal data, credentials or unrelated content appears, or the workflow requests live access, external action or source mutation.

Executed

No

Fixture status

Design only; no fixture, workflow or acceptance check has been executed.

Approval status

not_requested_or_granted_for_execution

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Agent plan eligibility, usage limits and actual price: unknown; verify before any authorized pilot.

2. Export preparation, line-ID reconciliation and AP review effort are unknown; a corrected native ERP report may eliminate the need for this separate analysis.

3. Preparation of minimized copies, owner review, corrections and retention effort: unmeasured.

4. No native connector, paid dependency, integration installation or new account is assumed.

Caveat

No numerical price, effort, saving, income or ROI claim. Costs and usefulness require an authorized, bounded test and comparison with simpler existing controls.

Canadian adaptation — proposed

Preserve metric/imperial units and the owner’s receipt conventions. If amounts are later added, have AP supply currency and applicable tax treatment; this quantity-only plan makes no Canadian tax or deployment claim.

Limits

1. Original editorial plan, not a source-documented agent case. No workflow, fixture or acceptance test was executed.

2. Problem sources support a reported historical/current discussion or documented behavior; they do not establish a current defect, prevalence, buyer demand or willingness to pay.

3. Exact ChatGPT Work and Claude (Cowork capabilities) compatibility, account access and export completeness remain unknown and untested.

4. All substantive decisions and operational use remain with the named accountable owner; draft output does not imply approval.

5. Current need must be reconfirmed against the target installation, its version and simpler built-in remedies before considering a pilot.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

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

   2. Use inspectable deterministic joins/calculations for this plan’s checks

   3. Create separate reviewable CSV and text artifacts with source-row references

   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 general documented primitives; this exact workflow has not been executed.

   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 the supplied synthetic structured/text copies without source-system access

   2. Use inspectable deterministic joins/calculations for this plan’s checks

   3. Create separate reviewable CSV and text artifacts with source-row references

   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 general documented primitives; this exact workflow has not been executed.

   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.