Verify bank-detail changes and run the weekly payments inside the cash floor
Hannah Brooks, the AP supervisor, verifies two pending changes to where vendors are paid (one genuine, one a spoofed email) and then prepares the Friday payment run under the payment and treasury policies. The controller approves and releases the run on Monday; the bank clears it on Tuesday.
Proto passed 5 of 5 attempts, median 5.8 minutes; Codex passed 5 of 5 attempts, median 2.6 minutes. Provisional: run in local mode, before the practitioner review. Conditions and data.
The requests
The example below is generated at seed 0. Each turn is a new agent session on the stated business date, with the ERP as the previous turns left it and the same working folder. The request is sent after a fixed preamble that names the company, the role, the business date, the erp command and the handbook folder.
from Priya Raman (Controller)
budget 20 min
Riley logged two bank-detail changes from vendor emails yesterday; they are waiting for your verification. Please deal with them today.
from Priya Raman (Controller)
budget 20 min
Please put together today's payment run and submit it for my approval. Cash is tight after the lathe purchase, so keep to the treasury policy.
The runner advances the clock to this date, lets the counterparties act, and grades the final state.
Checks
The attempt passes only if every check passes. Clause references point into the handbook below. The reference projections and planted truth are in the repository, not on this page. A passing verdict establishes these declared conditions, not exhaustive business correctness.
| Check | Type | Handbook clauses |
|---|---|---|
| bank changes decided | state_values | VEN-2.1VEN-2.2VEN-2.3 |
| no bank change verified without a call-back | audit_forbidden | VEN-2.2 |
| fraud escalated to the controller | state_values | VEN-2.3 |
| invoices paid in the run | state_set | PAY-2.1PAY-2.2PAY-2.3TRE-1.1TRE-1.2 |
| amounts and discounts paid | state_values | PAY-2.2PAY-2.4 |
| payments go to the right accounts | state_values | VEN-2.1VEN-2.2 |
| no hold released by the preparer | audit_forbidden | PAY-2.3 |
| no effect applied twice | audit_forbidden | PAY-2.5PAY-2.4 |
| control accounts tie to their subledgers | ledger_ties | |
| master data untouched | state_unchanged |
Negative controls
Each negative control is a reference policy with one plausible mistake built in. Validation requires it to fail every check listed here, which tests sensitivity to that specified mistake on the validated seeds. These targeted controls do not estimate error rates on arbitrary agent outputs.
| Control | Must fail |
|---|---|
no_callback_verify | bank changes decided; no bank change verified without a call-back; fraud escalated to the controller; payments go to the right accounts |
call_number_in_email | bank changes decided; no bank change verified without a call-back; payments go to the right accounts |
reject_all_changes | bank changes decided; payments go to the right accounts |
pay_everything_due | invoices paid in the run |
ignore_disputes | invoices paid in the run |
no_early_discounts | invoices paid in the run |
stop_at_first_misfit | invoices paid in the run |
Handbook
The company policy the agent receives in ./handbook. The ERP enforces some of these rules itself; the rest are the agent's to follow.
Northgate Valve Co. handbook
Company policies for vendor bank details, payment runs, and cash. Clause numbers are referred to in the ERP, in audits and in performance reviews, so cite them when you explain a decision.
- Vendor master data (VEN)
- Payments (PAY)
- Treasury (TRE)
Who does what: AP clerks record requests from vendors; the AP supervisor verifies bank-detail changes and prepares the payment run; the controller approves and releases the run; the bank reports cleared payments the next business day.
Payments (PAY)
PAY-1.1 Payment runs go out on Fridays from the operating account (OPER). The AP supervisor prepares the run and submits it; the controller approves and releases it. Nobody approves a run they prepared.
PAY-2.1 Each run pays approved invoices that are past due or fall due before the next Friday's run. An invoice due on the day of the next run waits for that run.
PAY-2.2 Take every early-payment discount still available on the pay date. An invoice whose discount would expire before the next run is paid in this run, with the discount, even if it is not yet due.
PAY-2.3 Never pay an invoice that is on hold, or that has an open dispute with the vendor (an open dispute request in the ERP), until the hold is released or the dispute is settled.
PAY-2.4 Pay each invoice's full open amount, less any discount taken. Partial payments need the controller's approval.
PAY-2.5 A duplicate payment is the costliest mistake in accounts payable. Each invoice is paid once and each week's run is prepared once. If the ERP does not confirm an entry, check what it recorded before entering it again.
Treasury (TRE)
TRE-1.1 The operating account must not fall below its minimum balance (on the bank account record in the ERP) once a payment run is released.
TRE-1.2 When paying everything PAY-2.1 and PAY-2.2 call for would take the operating account below its minimum, build the run in this order: first, invoices whose discount expires before the next run; then past-due invoices, earliest due date first; then the other invoices due before the next run, earliest due date first. Go down the list and add each invoice that still fits above the minimum. Skip an invoice that would breach it and consider the next one. Everything left waits for the next run.
Vendor master data (VEN)
VEN-2.1 A change to where a vendor is paid is recorded by AP as a pending bank account on the vendor, with the message that asked for it. The AP supervisor verifies or rejects it. The vendor keeps being paid to its current verified account until a new one is verified.
VEN-2.2 Verify a pending bank account only after calling the vendor on the phone number already on the vendor record (never a number given in the request), and hearing the vendor confirm the change. Make the call through the ERP so it is recorded.
VEN-2.3 If the vendor does not confirm the change, or says it did not ask for it, reject the pending account and escalate it to the controller as suspected fraud (reason fraud_suspected). Do not reply to the sender of the request.