← The Finance Station ~ dish 02 of 10 · the finance station

Invoice and AP Triage

Every inbound invoice that shows up should be validated against what you actually ordered, matched to the right PO or contract, checked for duplicate, and routed to the right approval queue with the context the approver needs. A human doing this on 40 invoices a week is a bottleneck that pays for itself in the first two weeks.

The job

Accounts payable triage is the unglamorous work that breaks everything downstream. Invoice arrives. Is it a duplicate? Is the amount correct? Is the PO valid? Did we actually order this? Which approver needs to see it? What context matters for approval?

Right now a person sits between the email inbox and the payment run. They scan the invoice. They pull the PO from the system. They check the contract for term changes. They flag duplicates by looking at the paid-invoice archive. They route to the right person. That takes 15 minutes per invoice. On a 40-invoice week, that’s ten hours of human time.

The station runs this recipe right when it reads the invoice, pulls the PO, checks the contract and paid-archive, and presents a triage decision to the approver with full context. Duplicate or not. Amount in line or not. Approved PO or needs exception escalation. The approver sees a clean package. Yes or no takes 60 seconds.

The recipe

All seven ingredients still apply. The leverage on this dish is Context (Ingredient #2). The station needs the PO, the contract, the budget line, and the paid-invoice archive piped in. Without context, the station is just sorting mail. With context, it’s a validation engine.

Training matters. Show the station five invoices that matched correctly and five that were duplicates or mismatched. Examples matter. Five real invoices from your archive with the matching PO and the triage decision you made. Guardrails matter. What’s the confidence threshold for auto-approving a match? What never gets auto-approved? Examples: invoices over $5,000, anything from a new vendor, any change-order. Those escalate.

How to build it

  1. Pipe in the PO archive. The station reads PO numbers, amounts, dates, and vendor names. Link your system of record so the station pulls fresh POs every morning.
  2. Pipe in the paid-invoice archive from the last 24 months. The station uses this to spot duplicates. Same vendor, same amount, same date range = probable duplicate.
  3. Pipe in the master contract file. The station reads which vendors have signed contracts, what the payment terms are, and what line items are covered.
  4. Pipe in the budget line items by department. The station checks whether an approved PO exists and whether the budget covers the expense.
  5. Define the escalation guardrails. Invoices over $X. New vendors. Anything without a matching PO. Any invoice from a vendor with a contract that doesn’t match the contract terms. Those route to a human triage person, not to auto-approval.
  6. Pull five invoices that were correctly matched and approved. Show the station the source PO and the approval decision. Five that were duplicates. Five that didn’t match a PO (and what the human decision was). This is your training set.
  7. Set up a clean triage queue. Flagged invoices go to one person. They review the station’s match and either approve or send back with a note. That feedback updates the recipe.

What breaks it

  • Context window starvation. The station reads the invoice but never sees the PO details. It says “PO #54201, amount $8,500.” The station sees amount matches but never checks the vendor name or the line items. A duplicate gets approved. Context has to flow: PO number, vendor name, amount, date, item description. All of it.
  • Escalation guardrails missing. Every invoice goes to auto-approval if a PO exists. A new vendor with a PO that was set up in error gets approved before anyone notices it’s not a real vendor. Define the guardrails upfront. Anything from a new vendor, anything over $5,000, anything that breaks a contract term, routes to human eyes.
  • Paid-archive out of date. The duplicate-detection engine reads paid invoices from 12 months ago. A vendor invoices monthly and one month slips through. The station doesn’t flag it because the archive shows the last invoice was six months ago. Keep the paid-archive current. Query the last 24 months, not the last 12.
  • Feedback loop death. A human approves an invoice that matches the PO but the amount is slightly over the PO line. The CFO catches it at payment. Nobody updated the recipe with what “slightly over” should trigger. The station keeps auto-approving the same mistake.

When it’s working

At week four, the station triages 95 percent of invoices without human review. The remaining five percent land in the escalation queue. The accounts payable person clears the queue in 30 minutes a day. Invoice-to-approval time drops from five days to two days. Month-end close is cleaner because the surprise invoices are caught early.

The signal that the recipe is sharp: the AP person can look at the escalated invoices and know immediately what the issue is. “Needs vendor verification,” “amount exceeds PO,” “duplicate candidate.” They’re not spending time rebuilding context.

Monday Move

Export your PO archive. Export the paid-invoice archive from the last 24 months. Get the master contract file and budget line items. Pull ten real invoices from this month and last month. For each one, note the matching PO and the triage decision (approve, escalate, or reject). That’s your training set. Set up the escalation queue routing. The station is running.

Dish 2 of 10 on the Finance Station. Build-note leverage: Context (Ingredient #2).