How to automate the three-way match without changing your ERP

What are the three documents in a three-way match?

A three-way match compares three documents before a supplier is paid. Each one answers a different question.

When all three agree on product, quantity and price, the invoice is paid. When they disagree, someone decides why. The match protects against paying for goods that never arrived, paying twice, or paying a price nobody agreed to.

The GRV (goods received voucher) is the South African name for the receiving document. Syspro calls it a GRN, and its documentation describes a Goods Received Notes suspense system for accounts payable invoice matching. SAP calls it a goods receipt. The GRV vs GRN article covers the names.

Where does the three-way match break in practice?

Most ERPs can run a three-way match. The logic is not the problem. The problem is that two of the three documents arrive clean and one does not.

The purchase order is created in the ERP by your buyer. The supplier invoice usually arrives by email as a PDF, and many finance teams already capture it well. The GRV depends on a paper delivery note, signed at a loading bay, that has to become a record in the ERP.

That is where it breaks. These are the usual patterns:

• The delivery note goes in a tray. The GRV is captured hours or days later, by someone who did not see the goods.
• The invoice arrives before the GRV. Finance cannot match it, so it waits, or it is paid against the purchase order alone.
• The delivery note carries no PO number. Finding the order means searching by supplier and guessing.
• A short delivery is captured as a full delivery, because the person capturing works from the PO rather than the note.
• A substitution goes unnoticed. The invoice names the substitute, the PO names the original, and the match fails for a reason nobody recorded.
• The supplier delivers cases of 24 against an order for cases of 12. The unit counts agree but the line counts do not.
• A purchase order is closed in full after a partial delivery. The balance vanishes, and so does the reason to chase it.

None of these is a failure of the people involved. They are the natural result of capturing a document far from where it was created, long after the goods were checked.

Why start with capture at the receiving bay?

The receiver standing next to the goods is the only person who knows what arrived. Every hour between the delivery and the GRV is an hour in which that knowledge fades and stock in the ERP is wrong.

Goods Receiving Automation moves capture to the bay. The receiver photographs the delivery note or proof of delivery on a phone or tablet browser, with no app to install. Multi-page notes and several photos are held together as one job. Glare, skew and poor light are handled.

Weeva reads the supplier, the delivery note number, the PO reference, every line and quantity, and batch and expiry details where they are printed. The photo stays with the record.

How is the right purchase order found?

Where a PO number is printed, Weeva looks it up among your open purchase orders in the ERP. Where it is missing or wrong, Weeva matches by supplier and by the lines themselves. If more than one open order fits, the receiver picks from a shortlist.

Searching by hand is slow when the reference is missing. Matching by lines rather than by reference also catches a note quoted against the wrong order.

How should tolerances be set?

A tolerance is the difference you are willing to accept without a decision. Set them too tight and every delivery needs attention. Set them too loose and real discrepancies pass.

1. 01Decide per discrepancy type, not one number for everything. An over delivery of fresh produce by weight is different from an extra carton of fasteners.
2. 02Start strict while running in parallel. You learn which differences are routine for which suppliers.
3. 03Never tolerate price differences silently. A price variance goes to finance; the PO price is never overwritten.
4. 04Treat substitutions and unordered items as decisions, always. They need a person to say yes.
5. 05Record damaged or rejected quantities separately, so the credit note has a clear basis.

Weeva compares ordered against delivered line by line, with the tolerances you set. It converts pack sizes to units before comparing, normalises units of measure where your catalogue allows, and names each discrepancy: short delivery, over delivery, substitution, price variance and the rest.

What happens when the receiver confirms?

The receiver confirms on the device, and their name goes on the record. Weeva creates the GRV in your ERP against the right purchase order, with the quantities actually accepted.

• Partial receipts are posted, and the balance stays open on the purchase order.
• Back-orders are left open, not closed by mistake.
• Batch, lot and expiry are captured where your ERP supports them.
• The photo of the delivery note travels with the GRV.
• Every action is recorded in the audit trail with the user and the time.

At this point the receiving step, a two-way match between purchase order and delivery note, is complete. It happened at the bay, while the goods were still there to check.

How does invoice matching change once the GRV exists?

With the GRV posted on time and with discrepancies named, the invoice is compared against a record that is already right. Three documents, one set of lines, every difference already explained.

An invoice for 100 units against a GRV for 90 is not a mystery. The GRV already says 'short delivery, 10 units, balance open'. An invoice naming a substitute product matches the substitution the receiver accepted. A price difference was flagged at the bay and is waiting for finance.

Matching the supplier invoice itself against the purchase order and GRV is scoped per engagement with Weeva. Some teams keep that step in the ERP, where the match logic already lives. Others add it once receiving is running.

What stays in the ERP?

Everything that is already there. You do not change ERP, and you do not change how purchase orders are raised or invoices are paid.

Weeva writes the GRV into the ERP by API, in the document your ERP uses: a GRV in Sage, a GRN in Syspro, a goods receipt in SAP. See the integrations page for each connector's status.

The quickest way to see this is on your own paperwork. Bring a few delivery notes and the purchase orders they belong to, and we will match them live.