Match Invoices to Purchase Orders and Completion Evidence
Match a supplier invoice to the purchase order and evidence of goods receipt or service completion.
- Author
- Ignacio Malpartida · GTM Engineer
- Published
- Read time
- 6 min read
Three-way matching needs the right third record
Match a supplier invoice to the purchase order and evidence of goods receipt or service completion. The third record depends on what was purchased. A delivery receipt can support a goods quantity, while a service invoice may require an accepted milestone or completion record. Do not invent a warehouse receipt for a service simply to fit a three-column checklist.
Start with line identity and consistent units. Ten boxes on a purchase order and one hundred units on a receipt may match if an approved conversion exists. Without that conversion, the numbers are not directly comparable. Preserve the original units and the applied conversion for finance to review.
Evidence needed to resolve the exception
Use this exception guide when reviewing a proposed Genie workflow or investigating a case that cannot proceed confidently. The tables describe operational decisions to configure in your environment. They are not claims that a connected application automatically supplies your organization’s policies, identity mappings, or approval process.
| System or owner | Evidence and responsibility |
|---|---|
| NetSuite | Flagged supplier invoices, purchase-order references, and potential duplicate records. |
| Postgres | Purchase-order evidence, goods receipts, or service-completion records. |
| Zendesk | Requests for missing evidence from suppliers or responsible departments. |
| Finance | Review and decision on the documented resolution; payment authority remains outside this workflow. |
Required context for this workflow design.
Treat duplicate detection as an evidence-backed review
Normalize invoice references for comparison while preserving their original values. Check supplier identity, currency, amount, date, and associated purchase order. A repeated number under the same supplier is worth investigating; the same number under a different legal supplier may be legitimate. Credit notes and replacement invoices also need their document relationships understood.
Use Zendesk to collect the missing context and document the result. If the supplier confirms a corrected invoice replaces an earlier one, record that relationship and send it to finance. Do not cancel records, approve invoices, or release payment based solely on a similarity score or a supplier’s informal statement. The useful automation is a review packet finance can verify quickly.
Decision table for common exceptions
Use the condition in the first column to choose the next action. The final column describes the boundary that must remain true while the case is unresolved. Apply the organization’s actual policy and source records to the live case; do not treat an illustrative condition as proof that the condition exists.
| Observed condition | Next action | Required boundary |
|---|---|---|
| Same amount, different service periods | Inspect scope and references | No automatic duplicate finding |
| Receipt quantity lower than invoice | Document exact line gap | Request missing evidence |
| Service completion missing | Ask responsible department | No fabricated goods receipt |
| All comparisons match | Prepare finance review packet | No payment authorization |
Exception decisions for supplier invoice exceptions.
Illustrative exception and recovery
Two invoices have the same supplier and amount but different monthly service periods. The workflow checks the scope and completion references before labeling them duplicates; repeated amounts alone do not establish duplicate billing.
This example uses fictional records to show the decision logic. It is not a customer case study or a claim of measured results. In a live case, retain the actual record IDs and evidence behind each statement, and replace all illustrative quantities or timing assumptions with the approved operational inputs.
What to record before resuming
A finance review packet with invoice and purchase-order lines, receipt or service evidence, duplicate candidates, Zendesk clarification history, and an explicit proposed resolution.
Preserve the original finding and the evidence that resolves it. Record which person or system supplied the clarification, which proposal it applies to, and the action now permitted. Do not erase the uncertainty from the history: a later reviewer needs to understand why the case paused and why it resumed.
Boundaries that remain in force
- Compare flagged invoices with purchase orders and receipt or service-completion evidence.
- Check possible duplicates using supplier and document context.
- Identify exact discrepancies and request missing information through Zendesk.
- Prepare a documented resolution for finance; never approve or release payment.
Review the case before restarting
First verify that the new evidence resolves the original blocker rather than a different issue. Then check whether the case, source records, or proposed action changed during the wait. A response attached to the right ticket can still be insufficient if it refers to an earlier proposal or leaves a required quantity, identity, or approval unresolved.
Run the relevant row from the decision table as a review scenario. Confirm that the job stops at the required boundary, asks for the specified information or decision, and resumes from the confirmed state. If a write or message may already have succeeded, inspect its destination before repeating it; if this job only prepares a draft or report, verify that it stays within that output scope.
- Exceptions with an exact line-level discrepancy
- Evidence requests routed to the correct supplier or department
- Finance packets with all source and clarification references
Track unresolved cases by their actual blocker and owner. A case waiting for clarification needs a different next action from one waiting for a confirmed result. Review the evidence when the state changes, and keep any still-unresolved completion condition visible instead of treating a successful intermediate step as the end of the work.
Give your Genie a job description
Copy the job description below. It preserves the scope and decision boundaries of this use case. Configure the referenced systems, record relationships, policies, and approval owners in your workspace before enabling the job.
Paste this into “Give your Genie a job description.” Explore Stacksync Genies.
Implementation references
These first-party references document the underlying records and interfaces. The cross-system sequence, approvals, and completion rules in this article are a proposed operational configuration; validate them against your connected workspace before enabling it.
FAQ
Frequently asked questions
Explore these integrations and topics
Related articles
