GRV Reconciliation: Three-Way Match for SA FMCG

GRV reconciliation in South African FMCG retail is a three-way match between the purchase order, the Goods Received Voucher, and the supplier invoice. The AP team compares product codes, quantities, unit costs, VAT, and RTS or claim lines so only matched deliveries are released for payment.

For a creditors clerk, the useful output is not a definition of a GRV. It is a payment-control workbook: one row per stock line, with the ordered quantity, received quantity, invoiced quantity, unit cost, VAT treatment, variance status, and payment decision visible in the same place. That is the practical job behind GRV reconciliation three-way match South Africa searches.

The generic receiving-document process is covered in the general GRN and GRV extraction workflow. This guide is narrower. It is for South African FMCG retail and wholesale AP teams dealing with high-line-count deliveries, supplier product codes, pack-size differences, short deliveries, damaged-stock RTS claims, and the User entered Tax versus System Tax comparison that appears in local accounting and inventory workflows.

The control principle is the same as wider three-way invoice matching controls, but the SA retail-trade version has its own document vocabulary and variance patterns. The GRV proves what receiving accepted. The PO proves what the store, branch, or DC ordered. The supplier invoice proves what the supplier wants paid. The reconciliation file has to make those three documents agree at line level before the payment batch is released.

The documents that feed the reconciliation file

A South African FMCG reconciliation pack usually starts with five document streams, not one. The purchase order shows what was ordered. The GRV shows what the receiving team accepted into stock. The supplier invoice shows what is being billed. The RTS or claim document shows what should be withheld because stock was short, damaged, rejected, or disputed. The credit-note or remittance trail shows whether the supplier eventually accepted the exception.

That document set sits between receiving and payment. In a DC, store, independent grocer, wholesaler, or buying-group environment, the receiving office may capture the GRV in Sage Pastel, Smart-IT+, Pastel Partner, Sage 50cloud Pastel Partner SA, or a comparable inventory system. AP then receives the GRV stack along with supplier invoices, portal downloads, and claim references. The clerk's work is not just to check that the header totals look plausible. It is to prove that every stock line being paid was ordered, received, invoiced correctly, and not already flagged for RTS.

The same pattern applies across Shoprite and Checkers suppliers, Pick n Pay and Boxer deliveries, SPAR DCs, Massmart and Makro receiving, Woolworths SA Food, Dis-Chem, regional wholesalers, and independent grocers. The trading partner names change, but the back-office question is the same: does the GRV prove the supplier invoice should be paid at line level?

This is where the workflow differs from general South African creditors clerk invoice processing. A role guide can describe supplier capture, statement checks, and payment preparation. GRV reconciliation is the line-by-line control inside that role: product code by product code, carton by carton, price by price.

For FMCG distributors, the same documents also matter in the opposite direction. A retailer-issued GRV or claim can come back as evidence for a deduction against the distributor's invoice, which is why supplier-side teams also need South African grocery retailer remittance and claims reconciliation. On the AP side, keeping the GRV, supplier invoice, RTS, and credit-note references together reduces the risk that a disputed line is paid once and then credited later without being matched back to the original delivery.

Extract these columns before matching GRV, PO, and invoice lines

The reconciliation file should preserve enough detail to join the documents without forcing the clerk back to the PDF for every query. Header fields identify the document chain. Line fields do the actual matching.

Useful header columns include:

• Supplier name
• Supplier code
• Retailer, branch, store, or DC code
• Delivery date
• GRV number
• PO reference
• Supplier invoice number
• RTS, claim, or credit-note reference where present
• Source document name or batch reference

Useful line columns include:

• Retailer item code
• Supplier item code
• Barcode, if present
• Description
• Pack size or case configuration
• Ordered quantity
• Received quantity
• Invoiced quantity
• Unit cost
• Discount
• VAT code
• VAT rate
• VAT amount
• Supplier VAT amount
• System VAT amount
• VAT difference
• Line total
• RTS or claim reference
• Match status
• Exception reason
• Payment or review decision

Preserving both the retailer item code and supplier item code matters in South African grocery and wholesale trade. A supplier invoice may identify a line by the distributor's product code, while the GRV or PO uses the retailer's stock master. If the workbook drops one of those codes, the match becomes a manual description search, especially where pack sizes differ between cases, inners, and singles.

For teams already capturing supplier documents in a Sage environment, Sage Pastel invoice scanning in South Africa is the platform-specific capture context. This GRV workbook is the next control layer: it uses the extracted fields from Sage Pastel, Pastel Partner Sage 50cloud SA, Smart-IT+, supplier portal PDFs, or scanned GRV packs to create a single line table for reconciliation.

Multi-page GRV line item extraction to Excel is especially important in FMCG replenishment. A delivery with hundreds of stock lines cannot be checked reliably from screen to screen if the PO, GRV, and invoice each sort or group products differently. The workbook should hold the raw extracted values first, then add calculated variance columns separately so the source values remain auditable.

How the three-way match flags quantity, price, and RTS variances

Once the PO, GRV, and supplier invoice are in the same workbook, the first join is usually the PO reference. The second join is the item identifier: retailer item code where the GRV and PO share it, supplier product code where the invoice uses the supplier's code, and barcode or description only as a fallback. The third check is economic: quantity, unit cost, VAT, and line total.

Quantity flags should separate the receiving issue from the billing issue. Ordered quantity versus received quantity identifies short or over delivery. Received quantity versus invoiced quantity identifies whether the supplier billed for stock the store or DC did not accept. A partial receipt should not be treated the same as a damaged-stock RTS line, because the follow-up evidence and payment decision differ.

Price flags need the same separation. A PO unit cost, GRV unit cost, and invoice unit cost can differ because of price-list changes, promotional pricing, settlement discounts, pack-size mismatch, or supplier error. The workbook should show the unit-cost difference and line-total difference instead of hiding the problem inside the invoice total. In grocery, a case-pack versus single-unit mismatch can look like a price variance until the pack-size column is reviewed.

RTS and claims need their own status, not just a comment. Damaged stock, rejected stock, missing cartons, supplier disputes, and awaiting-credit-note lines should be tagged so they stay out of the payable population until the supplier response is received. A claim reference links the disputed GRV line to later credit-note evidence.

Smart-IT+ strict reconciliation is the clean version of this control pattern: payment is held until the difference is cleared to zero. A Sage Pastel or Excel-based team may enforce the same discipline manually by using status flags such as matched and payable, quantity variance, price variance, VAT variance, RTS, awaiting supplier credit, and manual review.

VAT verification belongs at line level, not just invoice total

VAT checking is part of GRV reconciliation because FMCG deliveries can mix standard-rated and zero-rated goods on the same supplier invoice. SARS VAT standard and zero-rate guidance states that taxable supplies in South Africa are charged at either the standard VAT rate, currently 15%, or the zero rate of 0%. A grocery GRV can therefore include lines where the VAT amount is correctly zero and other lines where standard VAT applies.

That is why the User entered Tax versus System Tax comparison should be preserved in the workbook. System Tax is the VAT value calculated by the receiving or accounting system from the captured line data. User entered Tax is the VAT value taken from the supplier document. If those two values differ, the clerk needs to know which line caused the difference before the supplier invoice is released for payment.

Common causes are not all tax-law problems. A zero-rated item may have been coded as standard-rated by the supplier or in the stock master. A discount may have been applied before VAT in one system and after VAT in another. Rounding can differ across a large number of low-value grocery lines. A pack-size or quantity change can also move the line VAT because the taxable base has changed.

The workbook should therefore include VAT code, VAT rate, supplier VAT amount, system VAT amount, VAT difference, and review status. Checking only the invoice total can hide the line that needs correction, especially when several small VAT differences offset each other across a multi-page delivery.

Turning scanned GRVs and supplier invoices into Excel

In many SA retail and wholesale teams, the source pack is mixed. One supplier invoice arrives by email as a PDF. A GRV is scanned from receiving paperwork. A Sage Pastel or Smart-IT+ report is exported as a PDF. An RTS or claim document is downloaded from a supplier or retailer portal. The reconciliation problem is not that one document is unreadable; it is that the same stock movement is spread across different document formats.

Invoice Data Extraction fits this workflow when the AP team needs a consistent spreadsheet from that document pack. Users upload financial documents, describe the fields they want in a natural language prompt, and download structured Excel, CSV, or JSON files. For this use case, the prompt can ask for supplier code, GRV number, PO reference, item code, supplier item code, description, ordered quantity, received quantity, invoiced quantity, unit cost, VAT code, VAT amount, line total, RTS or claim reference, and match status.

That prompt should be written around the reconciliation file, not around OCR. For example, the team can ask for one row per line item and separate columns for PO, GRV, supplier invoice, VAT, RTS, claim, and exception status. The useful output is a table the clerk can sort, filter, and calculate against, not a text copy of the PDFs.

For larger GRV packs, volume matters. Invoice Data Extraction supports PDFs, JPGs, PNGs, batches of up to 6,000 mixed-format files, and single PDFs up to 5,000 pages. That makes it a practical way to extract GRV and supplier invoice data to Excel when the team is dealing with repeated supplier deliveries rather than an occasional five-line invoice.

From matched lines to payment, claims, and audit evidence

The reconciliation file should end in a decision, not just a variance report. Matched lines move into payment preparation. Short-received lines stay on hold until receiving confirms the delivery position. Over-received lines need approval before the extra stock is accepted or corrected. Price variances need supplier follow-up or finance-manager approval. VAT variances need review before capture. Damaged or RTS lines should remain linked to the claim or credit-note process.

For a South African FMCG AP team, those statuses are the control. They stop a supplier invoice from being paid in full when part of the delivery was rejected, billed at the wrong unit cost, miscoded for VAT, or still awaiting a supplier credit note. They also stop the opposite problem: a genuine matched line sitting unpaid because it is buried inside a disputed invoice.

The audit trail is built from the same columns. Each exception should retain the source document reference, extracted PO value, extracted GRV value, extracted supplier invoice value, variance calculation or flag, reviewer, decision date, and supplier response. When the supplier later issues a credit note or disputes the claim, the AP team can trace the line back to the original GRV instead of reconstructing the story from emails.

That is the practical value of treating GRV reconciliation as data. The team gets fewer blind spots across PO, GRV, supplier invoice, RTS, VAT, and payment status, while keeping the South African retail-trade evidence needed for supplier follow-up and internal review.