Playbook

Playbook: Build an Invoice Review Checklist Skill

A vendor invoice lands in the finance inbox. The senior AP analyst looks at it, applies a set of checks she has been running for years, flags one line item, ...

Agent Skillsagent-skills / playbook-invoice-review-checklist

A vendor invoice lands in the finance inbox. The senior AP analyst looks at it, applies a set of checks she has been running for years, flags one line item, queries the requestor, gets a clarification, approves it for payment. Quick. Reliable. Invisible. The next invoice comes in while she is at lunch — a junior analyst handles it, runs a different set of checks because nobody wrote the senior's rules down, and approves an invoice that should have been escalated for a missing PO reference. The error surfaces three weeks later when the controller reviews the month-end accruals.

The senior AP analyst's expertise is not in a system. It is in her head, in a Slack thread from 2023 where she once explained the review steps, and in a Google Doc nobody can find. When she takes PTO, the company's invoice review quality drops. When she eventually leaves or retires, the company loses the function. This playbook walks you through codifying that expertise as a reviewed Agent Skill — attached to your finance agent — so every invoice gets the same review whether the senior analyst is at her desk, on PTO, or no longer at the company.

What you will build

By the end of this playbook, you will have:

  • A workspace Agent Skill named Invoice Review Checklist with a SKILL.md procedure, the review rules codified, sensitive-data handling rules, escalation triggers for invoices requiring human review, and worked examples of clean and flagged invoices.
  • An approved version of that skill, attached to your Finance Agent with a readable mount path.
  • A repeatable workflow: an invoice arrives, the finance agent runs the reviewed checklist, the analyst gets either a "ready to approve" record or a "flagged for review with these specific reasons" record.
  • An audit trail: every reviewed invoice has a record of which checks were run, which findings were flagged, and what the analyst did with each finding.

What you need before you start

  • An Assist workspace where you can create workspace-scoped Agent Skills.
  • A workspace admin who can review and approve versions.
  • A Finance Agent in your workspace — the operational agent your finance team uses, ideally with tools that can read your AP system (NetSuite, QuickBooks, Bill.com, whatever you use) and read your PO records. If you do not have one, create a subagent and connect the AP tools first.
  • The senior AP analyst available to walk through her actual review process — twice, ideally on real invoices. This is the most important prerequisite. The skill encodes her judgment, not a generic AP checklist.
  • The controller or finance manager to define which findings count as escalation-worthy and which can be handled at the analyst level.

Step 1: Reverse-engineer the senior analyst's process

Get the senior analyst in a room and walk through five real invoices with her. Not "describe your process" — actually pull up real invoices and have her think out loud while she reviews them. Watch for:

  • The checks she runs first (PO match, amount sanity, vendor existence, tax handling).
  • The checks she only runs sometimes (and the trigger that makes her run them).
  • The questions she asks the requestor (and what answers she expects).
  • The findings she catches (and the ones she has been catching so often that they have become muscle memory).
  • The escalations she has made (and the ones she resolved without escalation).
  • The "smells" — patterns that make her suspicious even when no individual check fails.

Write everything down. The Slack thread from 2023 and the Google Doc nobody can find probably capture maybe 40% of what she actually does. The other 60% lives in her muscle memory, and the only way to extract it is to watch her work.

This is uncomfortable for the analyst — codifying expertise can feel like preparing to be replaced. Address it directly. The point is to make her expertise shared company infrastructure, not to remove her from the role. She becomes the owner of the skill, not the only person who can run the review.

Step 2: Classify the review rules

Every invoice review rule falls into one of these categories. Classifying matters because the skill needs to know what to apply universally vs. conditionally.

  • Universal checks. Apply to every invoice. Examples: vendor exists in the vendor master; invoice number is unique; total matches the line items; tax handling matches the vendor's tax profile.
  • PO-related checks. Apply only when the invoice references a PO. Examples: PO exists and is open; line items match the PO within tolerance; receipt has been logged; balance remaining is sufficient.
  • Threshold-driven checks. Apply when the invoice value crosses a threshold. Examples: invoices above $10K require dual approval; invoices above $50K require controller signoff; international invoices require currency-conversion verification.
  • Vendor-specific checks. Apply for vendors flagged in the vendor master. Examples: vendors with consent-decree handling, vendors under audit, vendors with custom payment terms.
  • Pattern-based smell checks. The senior analyst's intuition: round-dollar amounts, last-day-of-month dates, vendors with similar names, repeated invoice numbers with a suffix.

The senior analyst will recognize most of these from her work. The pattern-based smells are usually the hardest to articulate — push for specifics.

Step 3: Create the draft skill

Open Assist and go to Workspace > Agent Skills. Click New Skill and set:

  • Name: Invoice Review Checklist
  • Slug: invoice-review-checklist
  • Scope: Workspace
  • Description: Reviews a vendor invoice using the company's invoice review rules, applies universal and conditional checks, and produces either a ready-to-approve record or a flagged-for-review record with specific findings.

Or scaffold from chat:

"Create a workspace Agent Skill called Invoice Review Checklist. Slug: invoice-review-checklist. It reviews vendor invoices using the company's review rules, classifies findings, and flags invoices requiring human review. Start a draft SKILL.md and folders for templates, policies, and examples."

The skill is a draft. Nothing is mounted yet.

Step 4: Write the main procedure

Open /SKILL.md. The first line tells Assist when to pick this skill up:

Use this skill when a user asks to review, validate, or check a vendor invoice before approval for payment.

Then walk through the procedure. A useful SKILL.md for this skill includes:

  1. Confirm the invoice identifier (invoice number, system ID, or PDF reference). Refuse to review without one — invoice reviews that hallucinate input are a recipe for paying invoices that don't exist.
  2. Pull the invoice data from the AP system and the related PO record if one exists.
  3. Run the universal checks defined in /policies/universal-checks.md. For each check, cite the evidence (the value compared, the source). Do not infer — if the data is missing, mark the check as "could not verify" and continue.
  4. If the invoice references a PO, run the PO-related checks in /policies/po-checks.md.
  5. Apply threshold-driven checks based on the invoice amount and the rules in /policies/threshold-checks.md.
  6. Look up the vendor in the vendor master. If the vendor has flags, apply the vendor-specific checks in /policies/vendor-specific-checks.md.
  7. Run the pattern-based smell checks in /policies/smell-checks.md and flag any matches even if no individual check failed.
  8. Apply the sensitive-data policy in /policies/sensitive-data-rules.md. Invoices contain bank account numbers, tax IDs, and contract figures — the review record must redact what the company's data policy requires.
  9. Classify each finding by severity using the rules in /policies/finding-severity.md: informational, requires-clarification, requires-escalation.
  10. Produce the output in the format defined by /templates/review-record.md. If any finding is severity "requires-escalation," flag the invoice for controller review.

The procedure is what stops the agent from approving invoices the senior analyst would catch. Every check has a source. Every finding has a severity. Every escalation has a reason.

Step 5: Add the supporting files

  • /templates/review-record.md — the strict output format. Required sections: Invoice Summary (number, vendor, amount, date), Checks Run (with status per check), Findings (with severity and recommended action), Audit Trail (timestamp, agent version, analyst review status). The format is what makes the record auditable.
  • /policies/universal-checks.md — every check that applies to every invoice. Be specific: "Vendor exists in the vendor master" means the vendor name on the invoice matches an active record in the AP system's vendor master, with case-insensitive matching but flagging fuzzy matches as findings.
  • /policies/po-checks.md — checks that apply when the invoice references a PO. Include match tolerance rules (a 2% tolerance on quantity is acceptable; a 10% tolerance is not).
  • /policies/threshold-checks.md — checks driven by invoice value. Include the thresholds for dual approval, controller signoff, international currency verification.
  • /policies/vendor-specific-checks.md — special handling for flagged vendors. This is where the consent decree, audit, and custom payment-term rules live.
  • /policies/smell-checks.md — pattern-based heuristics. Round-dollar amounts, last-day-of-month invoices, fuzzy vendor name matches, invoice numbers that look like edits of recent invoices.
  • /policies/sensitive-data-rules.md — what gets redacted in the review record. Bank account numbers, tax IDs, and any vendor-specific contract figures must be handled per the company's data policy.
  • /policies/finding-severity.md — how findings are classified. Be opinionated. A fuzzy vendor name match is "requires-clarification." A PO mismatch above tolerance is "requires-escalation." A missing receipt is "requires-clarification" for small invoices, "requires-escalation" above threshold.
  • /examples/clean-invoice.md — a fully worked example of an invoice that passed all checks. Show what "no findings" looks like and why the audit trail still matters for clean invoices.
  • /examples/flagged-invoice.md — an example of an invoice with multiple findings at different severities. Show how the agent describes each finding, recommends action, and routes the escalation.

Drive the file work from chat:

"Draft /policies/smell-checks.md for the Invoice Review Checklist skill. Include the senior analyst's pattern checks: round-dollar amounts above $5K; last-day-of-month invoice dates; fuzzy vendor name matches against the master; sequential invoice numbers from new vendors; invoices in the first 30 days of a new vendor relationship. For each, define what should be flagged and at what severity."

Review every file. In finance, vague policy produces audit findings later. Be specific about every threshold, every tolerance, every smell.

Step 6: Submit for review and approve

From the skill detail page, click Submit for review. The senior analyst, the controller, and a workspace admin walk through the files:

  • Do the universal checks match what the team actually runs today?
  • Are the thresholds correct for the company's current authorization matrix?
  • Do the smell checks capture the patterns the senior analyst actually catches?
  • Does the sensitive-data policy match the company's data classification rules?
  • Does the worked example for a flagged invoice show the right recommended actions?

When approved, the version becomes available to mount. If rejected, the feedback comes back as comments. Author a new draft addressing the points — the skill file is the contract for what invoice review means at your company, and it will eventually face an auditor.

Step 7: Attach the skill to the Finance Agent

Open the Finance Agent and attach the approved version with a readable mount path:

/skills/invoice-review-checklist

Now the Finance Agent runs the reviewed checklist on every invoice it is asked about. The Slack thread from 2023 becomes irrelevant. The Google Doc nobody can find can be retired.

Step 8: Validate on real invoices

Pick five to ten real invoices spanning the variety: a clean PO-backed invoice, an invoice with a small PO mismatch within tolerance, an invoice with a fuzzy vendor name match, an invoice from a flagged vendor, a high-dollar invoice that crosses the controller-review threshold, and at least one invoice the senior analyst remembers catching something subtle on.

"Review invoice #INV-2026-0331 from Acme Logistics. It's a $14,200 invoice against PO #PO-9842."

"Review invoice #INV-2026-0445 from a new vendor. The invoice number ends in 'A' which is unusual."

"Review invoice #INV-2026-0512. The vendor name on the invoice is 'Acme Supply Co.' but our master has 'Acme Supplies Corp.'"

The senior analyst reads each review record and checks:

  • Did the agent run the right checks for the situation? In the PO-backed invoice, did it actually verify the receipt was logged?
  • Did the agent classify findings at the right severity? A fuzzy vendor name match should be "requires-clarification," not "informational" and not "requires-escalation."
  • Did the agent catch the smell checks the senior analyst would have? In the unusual-invoice-number case, did the agent flag it?
  • Is the recommended action specific enough for a junior analyst to act on?

Iterate by updating the skill files. If the agent missed a smell check the senior caught, the smell-checks policy needs to be more explicit. If the agent over-escalated routine items, the severity rules need refinement.

Step 9: Roll out and announce the change

Announce the change to the finance team and the controller:

"Starting Monday, the Finance Agent runs the reviewed Invoice Review Checklist on every invoice. The review record it produces is what we attach to the approval workflow. The senior analyst's review rules are now codified and version-controlled. Junior analysts still review the agent's output and handle escalations — the skill makes the first-pass review consistent, not automated."

Be clear about what changes and what does not. The skill does not approve invoices — it produces the review record. Analysts still own the approval decision. What changes is that the analyst is reviewing the agent's findings instead of running every check by hand, and the findings are produced consistently regardless of which analyst is reviewing.

Step 10: Improve the skill from real reviews

After a month of real use, patterns surface. Maybe the agent is over-flagging fuzzy vendor name matches that the senior analyst would dismiss based on context the agent doesn't have. Maybe a new vendor class needs custom handling. Maybe the controller decided that the dual-approval threshold should drop from $10K to $7.5K.

Open a new draft of the skill, update the policies, submit for review. When approved, deliberately upgrade the Finance Agent's attachment using the workflow in Governing Agent Skill versions. Old review records stay as written (which is correct for audit purposes — the record reflects the rules as of the time of review). New reviews use the new version. The audit trail in /templates/review-record.md includes the skill version, so the rules in effect for each invoice are always traceable.

What you built

You have a reviewed Agent Skill that codifies invoice review the way the senior analyst actually does it. The skill has:

  • The universal, PO-driven, threshold-driven, vendor-specific, and pattern-based smell checks all defined explicitly.
  • A sensitive-data policy that keeps bank account numbers and tax IDs handled per company policy.
  • A finding severity rule that distinguishes informational findings from escalation-worthy ones.
  • A review record format that produces an auditable trail for every invoice, with the skill version recorded.
  • A clear improvement path with version control, so the rules can evolve as the company's authorization matrix and vendor relationships change.

More importantly, you turned one analyst's expertise — built over years and stored in her muscle memory — into shared company infrastructure that the whole AP team can apply. The senior analyst becomes the owner of the skill, not the only person who can run the review. The junior analyst's first-pass reviews become consistent with the senior's. The controller's quarterly close reviews surface findings the team caught at the time, not findings the team missed because the senior was on PTO. The next auditor who asks "how do you review invoices?" gets pointed at the approved skill file, not at a Slack thread.

This is what bringing scattered AI use under one platform looks like in finance: one approved skill, one operational agent, one consistent review, with the rules actually documented and the audit trail actually intact.

Where to go from here

  • Add a vendor master maintenance skill. Invoice review depends on the vendor master being accurate. Build a sibling skill that flags vendor master records needing review: duplicates, dormant vendors, mismatched tax profiles, expired insurance certificates.
  • Add a month-end close prep skill. The findings from invoice review feed the controller's close prep. Build a skill that summarizes the month's review findings, flagged invoices, and resolved escalations — same playbook, different scope.
  • Connect a sandcastle dashboard. Build a sandcastle that shows invoice review trends: findings by severity, by vendor, by category. The review records this skill produces are the input data.
  • Standardize the expense report review. Expense reports have the same shape of problem — rules in one person's head, scattered guidance documents, inconsistent enforcement. The playbook transfers directly.