Step 0 — Orient from the ledger, not from memory
This is a fresh session — there is no prior turn to resume. {{ap_ledger}} is
the memory.
- Open
{{ap_ledger}} and read every existing row: vendor, invoice number,
amount, PO reference, and flag, so this run's duplicate check has the full
history, not just what one person remembers.
- Read the PO tab: open PO number, vendor, authorized total, and the agreed
price per line item — this is what invoices get matched against.
Step 1 — Pull new invoice email
Check {{invoice_label}} in Gmail for messages not yet reflected in
{{ap_ledger}} (match on Gmail message ID or thread ID recorded in the
ledger's last column). For each one, download the invoice attachment
(PDF, image, or embedded table).
Step 2 — Extract vendor, amount, and line items
From each attachment, extract:
- Vendor name and, if present, vendor ID/tax ID.
- Invoice number and invoice date.
- Total amount due.
- Every line item: description, quantity, unit price, line total.
- The PO number referenced on the invoice, if any.
If the attachment is unreadable (corrupt, wrong format, no amount visible),
record it in the ledger as unreadable with the email link and skip
matching — don't guess at numbers.
Step 3 — Match against the PO
- If the invoice references a PO number, look it up in the PO tab.
- No PO found (either no PO number on the invoice, or the number doesn't
exist in the tab) → flag missing PO.
- PO found → compare every line item's unit price against the PO's
agreed price for that item:
- Within tolerance (default: 2%, or whatever
{{ap_ledger}}'s notes
specify) → matches, no flag on price.
- Over tolerance on any line → flag overcharge, noting the line item,
PO price, and invoiced price.
- Compare the invoice total against the PO's remaining authorized balance
(PO total minus amounts already invoiced against it, per the ledger). An
invoice that would exceed the PO's authorized total → flag overcharge
regardless of per-line pricing.
Step 4 — Check for duplicates
Compare the new invoice against every existing row in {{ap_ledger}} for the
same vendor:
- Same invoice number already recorded → duplicate, exact.
- Different invoice number but same amount, same or near-identical line
items, and a date within 30 days of a prior invoice from the same vendor →
duplicate, likely resend — flag it, don't silently merge or drop it.
Step 5 — Record every invoice
Append one row per invoice to {{ap_ledger}}, flagged or clean: vendor,
invoice number, date, amount, PO reference (or "missing"), line items (or a
link to the attachment), flag (clean / duplicate / overcharge /
missing-po / unreadable), and the Gmail message ID so this run and future
runs can tell what's already processed.
Step 6 — Post the batch for approval
Post to {{approval_channel}}: every invoice processed this run, grouped
clean vs. flagged, each with its ledger row and (for flags) the specific PO
line or prior invoice it conflicts with. Ask for approval to proceed to
payment through the normal AP process — do not imply the agent has already
approved or scheduled anything.
Step 7 — Stop — never touch payment
Your last action is the Slack post. You never schedule a payment, mark an
invoice as paid, or write to any payment rail or accounting system beyond
{{ap_ledger}}. A clean match is still a person's decision to pay.