If you’ve ever spent a Friday afternoon manually “three-way matching” purchase orders, receipts, and invoices across email threads and spreadsheets—only to discover on Monday that you paid the same invoice twice—you’re not alone. **Three-way match exception workflow** problems hit SMB AP teams in the most annoying ways: missing receiving docs, unclear approvals, and last-minute vendor calls about overdue bills.
This post walks through a lightweight, practical approach to fixing that chaos using **Power Apps + Power Automate + Dataverse**. The goal isn’t to build an enterprise AP suite. It’s to build an **exception-based** process that auto-approves clean matches, routes only the messy cases to the right person, and leaves a clear control trail for audit and internal accountability—without turning your AP team into full-time spreadsheet detectives.
## Chapter 1: The AP Pain Point — Where Three-Way Match Breaks in SMBs (email approvals, missing receipts, duplicate invoices, late fees)
The real question isn’t “Do we have a three-way match process?”—it’s “Can we prove it happened, consistently, without heroics?” In SMBs, three-way match often exists as good intentions plus inbox archaeology.
Here’s what that looks like in practice: an invoice arrives by email, AP checks a PO in the ERP (or a spreadsheet), then pings operations for “proof it was received.” Someone replies with a photo, a packing slip, or “yeah it came in,” and AP makes a judgment call. Nothing is truly linked, nothing is truly standardized, and the “process” is scattered across systems that don’t talk.
### Where things go sideways
– **Email approvals become the system of record.** It’s fast—until someone is out, a thread is lost, or the approver changes their mind later.
– **Receipts are missing or delayed.** In many SMBs, receiving is busy and documentation is an afterthought. The invoice clock doesn’t care.
– **Duplicate invoices slip in.** Vendors resend invoices when they don’t get paid quickly, or invoice numbers vary slightly (e.g., “12345” vs “12345-1”). Fragmented intake makes it easy to miss duplicates. Audit guidance continues to flag duplicates as a common AP risk when controls are weak, as noted in AICPA guidance on AP controls and common risks.
– **Late fees and strained vendor relationships.** AP delays often aren’t caused by “not paying”—they’re caused by waiting for information that lives in someone’s head or phone.
All of that costs real money. Benchmark guidance regularly shows manual invoice handling is materially more expensive and slower than automated approaches due to rekeying, approvals, and exception handling, according to IOFM’s invoice processing cost overview. Even if you don’t automate “everything,” narrowing human effort to only the exceptions is where the ROI typically shows up first.
**Practical takeaway:** If your AP team spends more time chasing receipts and approvals than reviewing real issues (price/quantity/tax), you don’t have a matching problem—you have an **exception isolation** problem.
## Chapter 2: What “Exception-Based” Three-Way Match Means (auto-approve clean matches, isolate exceptions, preserve internal controls and audit trail)
**Exception-based three-way match** means you design the workflow so the “happy path” requires almost no human effort, and humans only touch invoices that fail a clear rule set.
Before diving into solutions, let’s understand the problem: most SMB workflows treat every invoice like a special case. AP opens every email, checks every line, pings someone for confirmation, and manually files the result. That’s backwards.
Exception-based matching flips it:
1. **Ingest the invoice** (file + key fields).
2. **Match it to PO + receipts** using rules.
3. **Auto-approve** when it meets criteria (including tolerances).
4. **Route exceptions** to the right resolver with a standard set of reasons and resolution actions.
5. **Log everything** (who did what, when, and why).
This is where it gets interesting: you can increase control and auditability while reducing work. The workflow becomes the control—rather than relying on “AP being careful.”
Modern finance automation guidance emphasizes straight-through processing for clean invoices and routing only exceptions for intervention, as described in Deloitte Insights on AP automation.
### What good looks like
A good exception-based model produces these outcomes:
– **Touchless approvals** for clean matches (documented automatically)
– **Standard exception reasons** (no more “random email explanations”)
– **A single timeline** per invoice showing match results, communications, approvals, and attachments
– **A clear segregation of duties** (AP vs. requestor vs. receiver vs. approver)
**Practical takeaway:** Don’t start by automating approvals. Start by defining the **match rules and exception taxonomy** (missing receipt, price variance, quantity variance, duplicate suspected, non-PO invoice, etc.). The workflow becomes simple once the rules are clear.
## Chapter 3: Data Model in Dataverse (vendors, POs, PO lines, receipts, invoices, match records, exception reasons, attachments, status history)
Most businesses get this wrong by trying to build the workflow in email and SharePoint folders, then wondering why reporting and auditability are painful. If the “truth” of the match lives in human conversation, you can’t scale it—or defend it during an audit.
Using Dataverse gives you relational structure, permissions, and auditing options that spreadsheets don’t, as explained in Microsoft’s Dataverse overview. It also supports role-based security and governance patterns, as noted in Microsoft’s Power Platform security guidance.
### A practical SMB-friendly Dataverse schema
You don’t need 50 tables. You need the right ones, with stable keys and a clean status model.
**Core tables**
– **Vendors**
– VendorID (from ERP), Name, Status, Default currency, Payment terms
– **Purchase Orders (PO)**
– PO Number, Vendor, PO Date, Total, Status
– **PO Lines**
– PO Line ID, PO, Item/Description, UOM, Qty Ordered, Unit Price
– **Receipts**
– Receipt Number, PO, Received Date, Received By, Location
– **Receipt Lines**
– Receipt, PO Line, Qty Received, Condition (optional), Notes
– **Invoices**
– Invoice Number, Vendor, Invoice Date, Amount, PO Number (nullable), Status, Source (email/upload)
– **Invoice Lines** (optional but recommended if line-level matching matters)
– Invoice, PO Line (nullable), Description, Qty, Unit Price, Line Amount
**Match + control tables (where the magic happens)**
– **Match Records**
– Invoice, PO, Match Outcome (Pass/Fail), Match Timestamp, Engine Version
– **Exception Reasons** (reference table)
– Code (e.g., MISSING_RECEIPT), Description, Default Owner Role, Severity
– **Invoice Exceptions**
– Invoice, Exception Reason, Assigned To, Due Date, Resolution Notes, Resolved By/On
– **Status History**
– Entity (Invoice/PO/Receipt), Old Status, New Status, Changed By, Changed On
– **Attachments**
– Linked to Invoice and/or Receipt (PDF invoice, photo of packing slip, email file)
### Two design decisions that save you later
1. **Use stable identifiers from the ERP** (VendorID, PO Number, PO Line ID) as alternate keys where possible. This reduces duplicates and mismatches.
2. **Track quantities at the PO line level** (ordered vs received vs invoiced). Without this, partial receipts and split shipments turn into manual chaos.
**Practical takeaway:** If you can only build one control table, build **Status History**. It turns “we think it was approved” into “here is the timestamp and approver.”
## Chapter 4: Power Apps Build — Capture Receipts and Resolve Exceptions (mobile receiving app, invoice intake screen, exception workbench, role-based views)
Your workflow will succeed or fail based on one simple factor: can the people closest to the work (receiving, project managers, department approvers) do their part in under a minute?
Power Apps is ideal here because you can create role-specific experiences without forcing everyone into the same screen.
### Mobile receiving app (simple and fast)
Receiving is often the bottleneck, so make it frictionless:
– Search PO by number/vendor
– Show open PO lines and remaining quantities
– Capture received quantities (including partials)
– Add photo attachments (packing slip, pallet label, delivery ticket)
– Submit receipt
Here’s what that looks like in practice: a warehouse lead receives a split shipment, records qty received against PO lines, snaps a photo of the packing slip, and hits Submit. The receipt immediately becomes matchable—no waiting for someone to “send it to AP.”
### Invoice intake screen (AP-focused)
AP needs a controlled intake point, even if invoices arrive by email.
– Manual upload (drag/drop PDF)
– Key fields: Vendor, Invoice #, Date, PO # (if present), Amount
– Optional: basic line entry for high-control vendors/categories
– Duplicate warning banner (based on Vendor + Invoice # + Amount + Date window)
If you later add OCR/extraction, this screen remains the “review and confirm” step rather than full manual entry.
### Exception workbench (where humans add value)
The exception queue should be the only place AP spends time.
– Filter by exception reason, vendor, aging, assigned to
– Show side-by-side: PO lines, receipts, invoice details, attachments
– Provide guided actions:
– Request receipt (notify receiver)
– Request PO correction (notify buyer)
– Approve variance (if within policy and authorized)
– Reject/return invoice to vendor
### Role-based views (controls without extra bureaucracy)
Dataverse security roles let you restrict who can:
– Create/modify receipts
– Approve exceptions
– Override tolerances
– Edit vendor master fields
This matters for audit and for preventing “helpful” edits that break the trail. Microsoft emphasizes governance and role-based access in Power Platform security documentation.
**Practical takeaway:** Don’t build one app. Build one solution with **three experiences**: receiving, AP intake, exception resolution. Each should be minimal and fast.
## Chapter 5: Power Automate Flows — Matching Logic and Routing (tolerances, partial receipts, split shipments, duplicate detection, approvals, notifications, SLA timers)
Power Automate is your enforcement layer: it runs the rules the same way every time and writes the “paper trail” automatically.
Approvals are a first-class feature with tracked outcomes (who approved, when, and result), per Microsoft’s Power Automate Approvals overview. That gives SMBs audit-friendly logging without building a custom approvals engine.
### Flow 1: Invoice ingestion → normalize → attempt match
**Trigger:** Invoice created (from AP intake screen or monitored mailbox)
**Steps (high-level):**
1. Normalize vendor (map sender/domain or selected vendor to VendorID)
2. Validate required fields (Vendor, Invoice #, Amount, Date)
3. Attempt PO link (explicit PO number, or search by vendor + recent POs if allowed)
4. Create Match Record “Pending”
5. Call matching logic (child flow) and write outcome
### Flow 2: Matching logic (rules, tolerances, partials)
This is where you decide what “clean” means.
**Recommended matching checks**
– **Vendor match:** invoice vendor must match PO vendor
– **Amount/price tolerance:** e.g., line price variance ≤ 2% or ≤ $50
– **Quantity check:** invoiced qty ≤ received qty (or received + allowed backorder rules)
– **Tax/freight handling:** separate lines or tolerance buckets
– **Receipt requirement:** for certain categories/vendors, enforce “no receipt, no pay”
**Partial receipts & split shipments**
– Maintain “received-to-date” per PO line
– Support multiple receipts per PO line
– Support invoices that cover partial quantities
– Prevent over-invoicing: total invoiced-to-date cannot exceed total received-to-date (or ordered-to-date, depending on policy)
### Flow 3: Duplicate detection (quietly prevents expensive mistakes)
Duplicate detection doesn’t need to be perfect; it needs to be conservative and reviewable.
Common rules:
– Exact match: VendorID + InvoiceNumber
– Fuzzy/secondary: VendorID + Amount + InvoiceDate ± X days
– Attachment hash (optional): detect identical PDFs uploaded twice
If suspected:
– Set status to “Duplicate Suspected”
– Route to AP lead for review
– Block payment export until resolved
This aligns with known AP control risks called out in AICPA’s AP controls guidance.
### Flow 4: Exception routing + approvals + timers
**If match passes:** auto-approve and set invoice status “Approved – Touchless.” Log it.
**If match fails:** create Invoice Exception(s) with standard reasons, assign owner, and start an SLA timer.
– Missing receipt → assign to Receiving role / specific location owner
– Price variance → assign to Buyer/Requester
– Non-PO invoice → route to department approver with justification required
**Timers & escalation**
– If exception not updated in 2 business days → escalate
– If invoice due date approaching → remind owner + AP
**Practical takeaway:** Make your “happy path” strict but fair. Use tolerances intentionally, and require a reason + approver for overrides.
## Chapter 6: Common Pitfalls and Control Gaps (bad keys, PO line mismatches, unit-of-measure issues, tolerance abuse, attachment handling, concurrency/idempotency)
This is the section that keeps your workflow from becoming yet another “almost works” tool.
### Common mistakes (and how to avoid them)
1. **Bad keys (no stable identifiers)**
– If users type vendor names freeform, matching will fail constantly.
– Fix: use VendorID, PO Number, and PO Line IDs as controlled lookups.
2. **PO line mismatch (invoice lines don’t map cleanly)**
– Many SMB invoices use vague descriptions that don’t match item master text.
– Fix: allow mapping invoice lines to PO lines during exception resolution, then “learn” that mapping for the vendor (simple reference table).
3. **Unit-of-measure (UOM) issues**
– “Case” vs “Each” is how clean matches become daily exceptions.
– Fix: store UOM on PO line and require conversion factors (even if it’s just a small table for top vendors).
4. **Tolerance abuse**
– If everyone can override tolerances, you’ve automated nothing.
– Fix: tolerance overrides require a specific exception reason, an approver role, and are written to Status History.
5. **Attachment handling that breaks audit**
– If documents live only in email, the record is incomplete.
– Fix: store attachments linked to invoices/receipts and restrict deletion permissions.
6. **Concurrency and idempotency (double runs cause double actions)**
– Power Automate flows can re-trigger or be retried.
– Fix: use an idempotency key (e.g., VendorID + InvoiceNumber) and check before creating new invoice records or launching approvals.
### A quick control checklist: Questions to Ask
– Do we have a **single system of record** for invoice status (not “who last emailed”)?
– Can we show **who approved** an exception and **why** (not just that it was paid)?
– Are tolerances documented and **role-restricted**?
– Can we prevent payment if an invoice is **duplicate suspected**?
– Can we report touchless vs exception rate by vendor/category?
Microsoft’s guidance around role-based security and governance is a helpful baseline for preventing accidental access and change issues, per Power Platform security documentation.
**Practical takeaway:** Treat exception handling as a controlled process, not a chat thread. The resolution notes and approval log are part of the control, not optional comments.
## Chapter 7: Measuring Success and Next Steps (KPIs like touchless rate, cycle time, prevented overpayments; rollout plan, scaling, and future AI-assisted extraction)
You’ll know this is working when AP stops talking about “tracking people down” and starts talking about “clearing the queue.”
### KPIs that actually matter
– **Touchless rate:** % of invoices auto-approved without human intervention
– **Exception rate by reason:** missing receipt vs price variance vs non-PO
– **Cycle time:** invoice received → approved (and separately, received → resolved for exceptions)
– **Prevented overpayments:** duplicates blocked, over-invoicing prevented
– **Aging by owner:** how long exceptions sit with each role/team
Tie these back to cost: IOFM notes the cost/time gap between manual and automated invoice processing is often substantial, as summarized in IOFM’s AP invoice cost guidance. Even modest improvements in cycle time and exception handling can translate into fewer late fees and fewer duplicate payments.
### Rollout plan (keeps it sane)
1. **Start with one vendor group or one department** (the noisiest one)
2. Implement **receipts + invoice intake + exception queue**
3. Add match rules and **tight logging**
4. Introduce tolerances and approvals after you’ve observed real variance patterns
5. Expand vendor coverage and add ERP integration (if/when needed)
### Next steps: AI-assisted extraction (later, not first)
Once the workflow is stable, AI/OCR can reduce data entry (invoice number, date, totals, line items). But automation guidance consistently shows the core value comes from routing and controls—not just reading PDFs. Build the process spine first; then add smarter intake.
**Practical takeaway:** Measure “touchless rate” weekly. It becomes your north-star metric and quickly exposes vendor/process issues you can fix upstream.
## Closing
Purchase order chaos usually isn’t caused by one big failure—it’s death by a thousand small mismatches, missing receipts, and email-only approvals. A practical **three-way match exception workflow** in Power Platform fixes that by doing two things well: automatically clearing clean invoices with a documented trail, and focusing human attention only where judgment is actually needed.
If you take nothing else from this guide, take these: define your exception reasons upfront, store match outcomes and status history in Dataverse (not inboxes), and treat tolerances as a controlled policy—not an escape hatch.
Take 10 minutes to list your top 5 recurring AP exceptions (missing receipt, price variance, non-PO invoice, duplicates, etc.). Which one shows up most often—and what would change if it had a standard workflow owner, SLA, and audit trail?
