Three-way match is the backbone of accounts payable control. Before paying a vendor, you verify three things: did we order this? Did we receive it? Does the invoice match both? Get all three right — you pay. If anything doesn't line up — you investigate.
In theory, simple. In practice, most AP teams spend 2–3 days every month doing it by hand — pulling up POs, cross-referencing receipts, flagging discrepancies, waiting on emails. NexuSphere AI automates the entire matching process: PO validation, receipt confirmation, invoice comparison, variance detection, and exception routing. Here's exactly how.
Step 1 — The Purchase Order anchors everything
Every P2P transaction starts with a PO — the commitment: X units of Y item from Z vendor at W price by a certain date. When a PO is created in NexuSphere AI, it records every line item with quantity and agreed unit price. Status starts at PENDING_RECEIPT.
This is the anchor document. Everything downstream — receipt, invoice, payment — is measured against it. Any deviation from what was agreed here triggers a flag.
Step 2 — Item Receipt confirms what actually arrived
When goods arrive, the receiving team creates an item receipt against the open PO — recording what actually came in: quantities by line item, date received. NexuSphere AI immediately compares received quantities against PO quantities.
Full receipt → PO moves to PENDING_BILL. Partial receipt → PARTIALLY_RECEIVED, remaining quantity stays open. At this moment the first GL entry posts automatically: Dr Inventory / Cr GRNI. Financial position recorded before the invoice even arrives.
Step 3 — Invoice matching runs five checks
When the vendor invoice arrives and is linked to the receipt and PO, NexuSphere AI runs five checks automatically:
- Vendor identity: Is the invoicing vendor the same as on the PO?
- PO reference: Does the invoice cite a valid PO that's open in PENDING_BILL status?
- Quantity match: Do invoiced quantities match received quantities — line by line?
- Unit price match: Are invoiced unit prices within agreed tolerance of PO price?
- Invoice arithmetic: Do line item totals compute correctly to the invoice total?
All five pass → clean match. Bill auto-approved, GL posts (Dr GRNI / Cr Accounts Payable), enters payment queue. AP team never sees it.
Step 4 — Variance detection: four types
Invoiced quantity doesn't match received quantity on one or more lines.
Invoiced unit price differs from agreed PO price, outside tolerance threshold.
Invoice references a PO that doesn't exist, is already closed, or belongs to a different vendor.
Invoice number matches one already processed for the same vendor. Prevents double payment.
Step 5 — Exception routing and resolution
Every variance routes to the Exception Queue with the specific reason code, the line in question, the variance amount, and a suggested resolution where the system can calculate one. AP works from the queue — not from a pile of PDFs.
Exceptions resolve three ways: approve-with-variance (accept the discrepancy), reject (return to vendor), or partial bill (approve matched portion, leave remainder open). Each resolution auto-posts the correct GL entry.
Every match, every variance, every resolution is fully auditable — the trail from vendor payment back to the originating PO and receipt is two clicks in either direction.
For a video walkthrough of a live PO, receipt, and invoice with a quantity variance running through this process in real time, see the video on the blog page.