> ## Documentation Index > Fetch the complete documentation index at: https://docs.cloudsquid.io/llms.txt > Use this file to discover all available pages before exploring further. # Invoice automation: vendor invoice audit > Cross-reference vendor invoices against POs and receipts — catch duplicates, price and quantity mismatches, and missed credits, with a starter SOP you can copy. ## The job AP receives vendor invoices and pays them. Somewhere between the PO, the goods receipt, and the invoice, things drift: a price that isn't the one that was agreed, a quantity billed that was never delivered, a credit note that was issued and never applied, the same invoice submitted twice under two numbers. Checking every invoice against its PO and receipt is exactly the work nobody has time for, which is why it's usually sampled — and why the errors that get through are systematic rather than random. This is the **continuous** sibling of [run an audit](/cookbooks/run-an-audit). That recipe runs these checks backward over 12–24 months of history to find money already lost; this one runs them on invoices as they arrive, before payment. Most teams do the lookback first — see [from audit to prevention](/concepts/audit-to-prevention). ## What you'll build ``` vendor invoices ──▶ Invoice Audit (reconcile table) ──▶ review ──▶ approved / disputed │ ├── queries ──▶ PO Master (storage) ├── queries ──▶ Goods Receipts (storage) └── queries ──▶ Credit Notes (storage) ``` * Each invoice becomes a case. * The agent matches it to its PO, checks the received quantities, compares line prices against agreed prices, looks for duplicates and unapplied credits, and produces an audit verdict. * Clean invoices come back `pass`. Everything else comes back with the specific discrepancy, the amount at stake, and the evidence. ## Ingredients | | | | ------------------- | -------------------------------------------------------------------------------------- | | **Reconcile table** | `Invoice Audit` | | **Storage tables** | `po_master`, `goods_receipts`, `credit_notes`, `vendor_master` | | **Model tier** | **Balanced**; **Powerful** for multi-page invoices with long line detail | | **Integrations** | Optional: `invoices@` mailbox intake, and a push of the verdict back to your AP system | | **Auto Review** | Enable only for `pass` verdicts under your escalation threshold | ## The starter SOP ```md theme={null} # SOP — Vendor invoice audit Version 1.0 · Owner: Accounts Payable · Last approved by: , ## Purpose Verify each vendor invoice against its purchase order and goods receipt before it is approved for payment. Report discrepancies with evidence. Do not correct the invoice. Do not approve payment. ## Step 1 — Match the invoice to a PO Match in this order, stop at the first hit: 1. PO number quoted on the invoice → exact match in `po_master`. 2. Vendor + invoice line articles + date window (invoice date minus 90 days) → single open PO with matching articles. 3. No match → `po_match_status: unmatched`, list up to five candidate PO numbers with vendor, date, and open amount. Stop here. Confirm the vendor on the matched PO equals the invoicing vendor in `vendor_master`. If not, flag — never override the vendor. ## Step 2 — Duplicate detection Before checking anything else, look for a duplicate: - **Exact duplicate**: same vendor + same invoice number → `duplicate: true`, verdict `fail`, name the earlier case. Stop. - **Near duplicate**: same vendor + same total amount + invoice dates within 10 days, different invoice number → `duplicate: suspected`, verdict `needs_confirmation`. List the other invoice. Do not decide. - Same vendor and amount more than 10 days apart with different articles is not a duplicate — recurring charges look like this. ## Step 3 — Quantity check against receipt For each invoiced line, compare the billed quantity to the received quantity in `goods_receipts` for that PO line. - Billed ≤ received → pass. - Billed > received → `quantity_variance` with the difference. Partial deliveries are normal; billing ahead of receipt is not. - No receipt at all for the PO line → flag as `not_received`. Service lines without a receipt are expected — say so rather than failing them. ## Step 4 — Price check against the PO Compare each invoiced unit price to the agreed price on the PO line. Tolerance: the smaller of **2%** or **10.00** per unit. - Within tolerance → pass. - Above tolerance → `price_variance` with agreed price, billed price, the per-line difference, and the total exposure across the invoice. - Below the agreed price → report it too. An unexplained discount is a data problem worth knowing about. Currency must match the PO. A different currency is always a flag, never a conversion. ## Step 5 — Credit note check Search `credit_notes` for open credits from this vendor that reference this PO, this invoice, or any of its articles. Any open credit not applied on the invoice → `unapplied_credit` with the credit number and amount. ## Step 6 — Verdict Set exactly one: - `pass` — matched to a PO, no duplicate, quantities and prices within tolerance, no unapplied credits. - `needs_confirmation` — resolved, but a human should confirm before payment: suspected near-duplicate, a variance inside tolerance but on a high-value line, a service line with no receipt, or a price variance the vendor has a documented reason for. - `fail` — a definite problem: exact duplicate, unmatched PO, vendor mismatch, quantity billed over received, price variance above tolerance, or an unapplied credit. The middle bucket matters. Most invoices are not clean-or-broken — they are fine but worth a glance. Do not push those into `pass` to look tidy, and do not push them into `fail` and bury the real problems. ## Escalation thresholds - Total exposure above **5,000.00** → always a human, whatever the verdict. - Any new vendor with no prior invoices → always a human. - More than three flagged lines on one invoice → escalate the whole invoice rather than reporting line by line. ## Outputs Fill every output field. In the comment, state: which PO it matched and how, what you checked, every discrepancy with its amount, and the total exposure. A reviewer should be able to decide without opening the PDF. ``` ## Walkthrough Create `po_master`, `goods_receipts`, `credit_notes`, and `vendor_master` as **Storage** tables. Keep them current with a scheduled [workflow](/concepts/integrations) against your ERP — stale PO data produces false variances, which is the fastest way to lose your reviewers' trust. `Invoice Audit`, with **Operating Procedures**: `Audit incoming vendor invoices according to the SOP.` **Output Fields**: `invoice_number`, `vendor`, `po_number`, `po_match_status`, `duplicate`, `quantity_variance`, `price_variance`, `unapplied_credit`, `total_exposure`, `verdict`, `flags`. Grant **Data Access** to all four storage tables. Run last month's invoices — a set where you know what was clean and what wasn't. It calibrates the tolerances and shows you what the agent flags that your process currently misses. Work the `fail` cases first, then `needs_confirmation`. Comment with the rule, not the outcome: "this vendor's framework agreement supersedes the PO price — check the agreement before flagging" is something the SOP can absorb. ### What good looks like **A clean pass:** > Matched invoice INV-77301 to PO 4500219 on the quoted PO number; vendor Halvard Supply matches. No duplicate — no other Halvard invoice at 3,412.00 in the last 90 days. All 4 lines received in full. Prices match the PO exactly. No open credits for this vendor. Verdict: pass. Exposure: 0.00. **A case the agent correctly refuses to resolve:** > Invoice INV-77354 from Halvard Supply, 3,412.00, dated 4 days after INV-77301 for the same amount. Different invoice number and different article on line 2 (ART-5590 vs ART-5591), so this is not an exact duplicate — but the amount and window match the near-duplicate rule. `duplicate: suspected`, verdict `needs_confirmation`. Both invoices listed. Not deciding: the article difference could be a genuine second delivery or a re-issue with a typo, and the vendor's remittance history doesn't distinguish them. The agent did the whole comparison and then stopped exactly where the evidence stopped. That's a ten-second decision for AP instead of a twenty-minute investigation. ## Iterating Vendor-specific reality is what the starter SOP can't know. It arrives through review comments: > Reviewers keep overriding price variances for Halvard Supply — they have a framework agreement with quarterly price steps that the PO doesn't reflect. Add a rule: for vendors with a framework agreement, check the agreement price before flagging a variance, and flag the PO as stale instead. Then run [the improvement loop](/concepts/improvement-loop) monthly against the accumulated review feedback. ## Hardening Route `invoices@` into the project so cases are created as invoices arrive. Enable **Auto Review** so clean invoices under your threshold clear automatically and AP works the exceptions. A workflow writes the audit result onto the invoice in your AP system. It stays the system of record; nothing pays without approval. At volume, structure invoice headers and line items first, then audit the rows. The same checks over 12–24 months of history — read-only, and usually where teams start. Why the lookback comes first, and what changes when these checks go continuous. All vendor names, invoice numbers, article numbers, and amounts in this cookbook are invented. Replace them with your own data.