Appearance
W3: Accounts Payable agent
In plain terms. When a bill lands in the inbox, somebody on the finance team has to decide when to pay it, from which Reap balance (Card, Pay, or Optimize), and whether it is safe to pay at all. This skill does that work and hands the controller a payment plan to confirm. Before it picks a date or a balance, it runs two fraud checks: is this a duplicate of a bill we already saw, and is the vendor's bank account the one we used last time? If either check fails, the bill is held and a controller is paged — no payment date is proposed at all, because there is no point planning an elegant payment for a bill that might be fraudulent. Even on a perfectly clean bill, this skill will never move money on its own. The strongest answer it can give is "I suggest you pay it this way." Execution always sits with a human.
The brief is the longest of the three because the pain is the most multi-dimensional. Open it once and the "fraud gates run first" decision later on this page will read as obvious rather than cautious.
Assignment brief — Workflow 3
Ingest invoices (email / OCR) → extract and validate → run an approval state machine → forecast cash across Reap Pay and Optimize balances → recommend (or execute) payment timing and source-of-funds, optimising for FX cost, early-pay discounts, and yield on idle balances.
The pain isn't "pay the invoice"; it's: invoices arrive as PDF attachments to ap@company.com (and PNGs, and forwarded JPEGs of phone photos) and extraction is manual. Approval routing depends on vendor, amount, GL code, and entity — usually a spreadsheet and a Slack ping. "When and from which balance do I pay this?" is a multi-variable problem nobody actually optimises: FX cost, funding cost, early-pay discount, Optimize yield foregone, settlement timing. Duplicate invoices and fraudulent bank-account changes leak real money.
This skill triggers on every bill event and produces a payment plan for controller review: when to pay, which Reap rail to use, expected foreign-exchange cost, discount economics, and whether dual control is required. Money movement is never auto-applied.
In the product, the output of this skill shows up in two places: the bills page, where every upcoming payment is listed with its schedule and funding context, and the decision detail panel, where the agent's recommendation is laid out beside the evidence and approval path so a controller can confirm without leaving the screen.
The detail panel is the part to study. The agent's recommendation lives next to the evidence that produced it and the dual-control state — three pieces of information the controller would otherwise have to assemble from a spreadsheet, an email, and a Slack thread.
What it produces
A controller does not see raw JSON in the product — they see the bills page row — but reading the structured output makes the skill's job concrete. Every recommendation is a single object that bundles five things together: when, urgency, which balance to draw from, the foreign-exchange cost the system estimated, the discount math, and whether two signatures are required.
ts
{
paymentDate: "2026-05-20",
urgency: "scheduled",
sourceOfFunds: "reap-optimize",
expectedFxCostUsdMinor: 571,
discount: { netUsdMinor: 100000 },
approval: { dualControlRequired: true }
}Overdue bills escalate to outcome.escalate("controller", ...) instead of hiding inside the normal queue.
The expectedFxCostUsdMinor and discount.netUsdMinor fields together let the controller see the trade-off in dollar terms before approving. The same plan that costs $5.71 in foreign exchange might unlock a $1,000 early-pay discount, or it might not — the math is on the row, not in someone's head.
Rail decision chart
The sourceOfFunds field in that payload is the most consequential choice the skill makes. Picking the wrong rail can mean paying foreign-exchange twice, missing an early-pay discount, or drawing on a yield balance that the customer wanted preserved. The rule of thumb the skill uses comes down to three rows.
Reap PayCross-currency / United States Dollar Coin corridoravoids double foreign exchange when the vendor currency differs
Reap CardSame-currency ≤ United States dollar 5kfastest settle, simple reward path
OptimizeSame-currency > United States dollar 5kdraw yield balance while preserving working capital
The $5,000 threshold is a tunable, not a law — it is the point where the convenience of Card stops being worth the working-capital cost. Reap Pay is the only rail picked specifically for non-monetary reasons (avoiding a double foreign-exchange hop), which is why it sits at the top of the chart.
Decision flow
The rail logic above only runs once the bill is judged safe to pay. Here is the full sequence for one bill, with the safety step put deliberately before the optimization step.
BILL
BillEvent with due dateThe skill refuses missing due dates and escalates fraud holds before it proposes a payment plan.
↓
$
Compute deterministic planScheduling, source-of-funds choice, foreign-exchange cost, discount optimization, balance checks, and dual-control gates all run as code.
↓
NO
Never auto-apply money movementEven at the autonomous rung, accounts payable returns suggest, escalate, or refuse. Execution remains human-ratified.
↓
LOG
Decision log + queueThe payload records source of funds, foreign-exchange estimate, urgency, rationale, and approval state for the operator.
The third step deserves a second look: even at the highest tenant autonomy setting, this skill cannot return autoApply. That is enforced by the skill's own type signature, not by a runtime check that someone could forget to wire up. It is the strongest single safety property in the whole submission.
Risk gates
The "fraud checks first" step in the flow above is not a single check — it is a panel of six gates the bill has to pass before scheduling even runs. Red gates stop the bill cold and page a controller. Gold gates surface for review but do not block. Green gates inform the funding choice rather than denying it.
bank-account changeHard hold and controller escalation.
duplicate invoiceContent hash / near-duplicate signals.
overdueEscalate, do not refuse.
discount windowCapture only when net of yield foregone is positive.
balance-aware fundingChoose sleeve without creating hidden shortfalls.
≥ United States dollar 10kDual control required before execution.
Three red, two gold, one green is the right shape for a payment skill. The agent's bias is toward stopping, not toward shipping — that bias is the protection the controller is paying for.
Key design choices
The single biggest call I made on this skill is what it will not do. The brief invites the agent to recommend or execute payment timing. I deliberately stopped at recommendation.
Why recommendation-only is the right minimum viable productThe valuable demo is not fake execution. I wanted to show that the agent can build a defensible accounts-payable plan, name its risk gates, quantify foreign-exchange/discount trade-offs, and route high-value bills through dual control before any money moves.
The execution seam is real — the funding rail picker would call into the existing Reap Pay APIs, the same way the rest of the platform does. What is missing is the production rollout work (canary tenant, dual-key approval flow, rollback runbook), which is the right place to spend the next sprint, not the next take-home.
Testing & evals
Two layers — an 18-case runtime golden corpus and 8 AP-optimizer boundary cases pinned in Vitest — moved to their own page so the corridor / discount math can be regressed independently from end-to-end planning. The two refusal cases (missing FX, hostile invoice) are the load-bearing ones.
- Accounts payable — evals — two-layer testing on the highest-stakes path.
Read next
The worked example walks through two real cases from the seeded demo: a duplicate Quang Nguyen Engineering invoice (107,594,937 Vietnamese dong, four days apart) and a Halborn invoice (USD 18,986) that quietly changed the destination bank account. Both are caught and held before a payment plan is computed — the clearest demonstration of why fraud gates run first, plus the five design patterns that make the recommendation-only stance structural.
- Worked example — the duplicate invoice and the bank-change cases, end to end.
Next skill in this section: Daily pulse — the only skill that wakes up on its own. It reads the decision log that the first three skills write to, and turns it into a morning brief for the CFO.