Goods Received Not Vouchered (GRNV): Meaning and Workflow

Goods received not vouchered (GRNV), often shortened to received not vouchered (RNV), means goods have been formally received against a purchase order, but the supplier invoice has not yet been matched and converted into a voucher in the AP system. Whichever of those phrasings appears on your report, the underlying state is the same: the receipt is on the books, the payable side of the transaction is not.

The journal mechanic is short. At receipt, the system debits inventory or expense and credits the Received Not Vouchered (RNV) account. When the supplier invoice arrives and the three-way match succeeds, a voucher is created: that voucher entry debits RNV and credits accounts payable, with any tax adjustment applied at the same time. At payment, accounts payable is debited and cash credited. Two entries, in other words, sit between physical receipt and cash leaving the bank, and the RNV account is the holding place for the obligation between them.

That holding place is an accrued liability. It is not a permanent account; every line in it is an in-flight obligation that should clear once the supplier invoice is posted, matched, and vouchered. The reason the account exists at all is accrual-basis accounting: per U.S. Department of Veterans Affairs financial policy on liability recognition, an exchange transaction is recognized as a liability in the period that goods or services are received in return for a promise to provide money or other resources in the future. The receipt of goods creates the obligation; the supplier invoice arriving later is paperwork, not the liability event. RNV is what the accounting system uses to honor that timing.

Why Some AP Systems Use "Vouchered" Instead of "Invoiced"

A voucher, in an AP-system sense, is a posted, payable internal record built by matching an inbound supplier invoice to its purchase order and to the receipt that confirmed the goods arrived. It is the system's representation of a validated, ready-to-pay liability. Until that record exists, the obligation lives in the RNV account; once it exists, the obligation has moved to accounts payable and is queued for payment.

That distinction matters because in a voucher-language system the supplier invoice on its own does not unlock payment. The invoice has to be received, posted, matched against the PO and the receipt, and only then converted into a voucher. Voucher matching in AP is the validation step that bridges supplier paperwork and a payable obligation; it is what every voucher-language ERP is operationally organized around. So a system that processes AP through voucher records naturally reports its open-receipt liability in voucher language: the report is not asking "have we received the invoice?" — it is asking "has a clean voucher been built yet?"

In that frame, each receipt sits in one of three states. Unvouchered means no invoice has been posted yet, or an invoice has been posted but matching has not begun — the receipt is on the books and nothing on the AP side has caught up. Partially vouchered means matching is underway but unresolved: some quantity or amount has matched to an invoice line and a partial voucher exists, while the remainder is still open. Fully vouchered means a clean match has produced a voucher that supersedes the RNV entry, so the line drops off the report.

Oracle JD Edwards is the most visible example of an ERP built around voucher vocabulary, and its Procurement Management documentation describes the open-voucher-by-receipt view in exactly those terms, including the note that a formal receipt credits a Received Not Vouchered account. Several other ERPs use the same family of language. The reader may be on JDE, SAP, Oracle Fusion, Dynamics, NetSuite, or a smaller industry-specific system; the underlying logic is the same wherever an AP system treats a posted voucher as the unit of payable liability rather than treating the supplier invoice directly.

The mapping the searcher came for is therefore straightforward. When a report says "received not vouchered," the system behind it processes AP through voucher records and is reporting the gap between physical receipt and matched supplier invoice in its native operational vocabulary.

GRNV vs GRNI: The Same Liability Under Two Names

GRNV (goods received not vouchered) and GRNI (goods received not invoiced) describe the same accrued liability — the gap between physical receipt of goods or services and a fully matched, payable supplier invoice. The terms differ only in which side of that gap each naming convention chooses to emphasize. Once that point is clear, the received not vouchered vs goods received not invoiced distinction stops being mysterious and becomes a vocabulary preference.

GRNI frames the gap from the invoice side: goods have arrived; the supplier invoice has not yet been recorded against them. GRNV frames the same gap from the voucher side: goods have arrived; the matched, payable voucher record has not yet been created. Both labels point at the same balance-sheet entry — an accrued liability for goods or services received without an offsetting payable yet posted to AP.

The wording does carry one practical nuance. "Not invoiced" usually means the supplier invoice has not been entered into the AP system at all. "Not vouchered" can mean either: (a) the invoice has not been entered, or (b) the invoice has been entered but is unmatched, sitting in an exception queue, or otherwise blocked so no voucher has been built from it. The voucher-side framing therefore captures a slightly broader set of open situations under the same line item on the report.

The two labels also tend to surface in different parts of the conversation. GRNI is more common in finance reporting, audit discussions, and accrual close commentary — the language a controller or external auditor reaches for when describing the liability. GRNV (or RNV) is more common in ERP report names, reconciliation reports, and day-to-day AP work inside systems that natively process payables through voucher records. Same liability; different operational vocabulary.

For readers who need the broader accrual mechanic, the monthly reconciliation procedure to the GL control account, and a fuller walk-through of the close-side workflow, the goods received not invoiced (GRNI) workflow article covers that ground in detail. The rest of this article stays in voucher language and focuses on the parts of the workflow specific to RNV reporting and clearing.

What a Received Not Vouchered Report Actually Shows

A received not vouchered report lists every receipt that has been posted to inventory or expense but does not yet have a matched, fully vouchered supplier invoice behind it. Each line is an open piece of the RNV account balance; the report is the operational view of that balance, broken down by the receipt that created it. If the report total reconciles to the RNV GL account, the report is doing its job.

The fields fall into two groups. The first group identifies the obligation: supplier name and supplier number, purchase order number and PO line, receipt number, receipt date, item or service description, and the business unit or cost center the receipt was posted to. Those columns tell you which supplier you owe, against which order, for what.

The second group sizes the obligation in money. Quantity received, unit cost, extended receipt amount, tax where applicable, and the open RNV amount itself. The open amount is the figure that rolls up to the account balance; it is also the figure that adjusts down as partial vouchers post against the line.

Sitting between those two groups are the matching-state and aging columns, which signal whether a line is normal or a problem. Voucher status (or match status) classifies each line as unvouchered, partially vouchered, or fully vouchered — sometimes shown as a MATC indicator or its equivalent. An invoice number appears once the supplier invoice has been posted but the match has not yet completed; that is often the most diagnostic field on the report, because a posted invoice with no voucher means the line is stuck in matching rather than waiting on the supplier. Where partial matching has occurred, a partial-voucher amount shows what has cleared and what remains open. And receipt aging — current, 30, 60, 90+ days from the receipt date — tells you which lines are operationally normal in-flight and which are aged enough to need active investigation.

What the standard report does not always show, but the underlying data can usually surface in a variant, is the higher-level view: supplier-level summary totals for executive review, aged-bucket breakdowns for close and audit, and reconciliation status to the general ledger control account. Those are typically separate reports in the same family or filter views on the same dataset.

The accuracy of the whole report depends on clean receipt data going in. The quantities, unit costs, and tax amounts the system uses to compute open RNV balances all come from the receipt record, which in turn typically comes from a goods received note. AP teams who depend on supplier-side GRN documents — particularly in three-way-match environments where the GRN is the system of record for what arrived — will recognize that extracting goods received note (GRN) data cleanly and consistently is a precondition for an accurate RNV report. Garbage in produces an RNV report no one can reconcile.

Investigating an Open RNV Balance

Every open RNV line should resolve into one of three end states: match the receipt to an existing or arriving supplier invoice and create the voucher; reverse the receipt because it was posted in error; or accept the line as a known exception with a documented reason. Open RNV balance investigation is the work that pushes each line toward one of those outcomes. Everything below is the same conceptual work whether the AP team is on JDE, SAP, Oracle Fusion, Dynamics, NetSuite, or a smaller ERP — only the screens differ.

Start with the invoice. Is one in the system at all — sitting in the AP inbox queue, in an exceptions folder waiting on a coder, or posted but unmatched? If nothing exists, the next move is the supplier: confirm the invoice has been issued, request a copy if it has, and chase if it has not. A receipt that is aged beyond normal cycle time with no invoice on either side is the most common single cause of an aged RNV line.

If the invoice exists, the investigation moves to quantity. Does the invoiced quantity equal the quantity received? A partial-delivery situation typically resolves through a partial voucher for what arrived, leaving the remainder open as a smaller RNV line against the same PO; treating partial deliveries as failed full matches is one of the more common reasons RNV reports inflate.

From quantity the work moves to price: do the unit costs on the invoice line up with the PO price and the receipt-posted unit cost; are tax codes consistent across PO, receipt, and invoice; is any variance within tolerance for the matching engine or outside it. Finally, check the receipt itself — was it posted against the right PO line, was it duplicated against another PO or another receipt of the same goods, was the recorded quantity higher than what physically arrived.

All of this is three-way matching across PO, GRN, and invoice: AP is comparing what the PO authorized, what the receipt confirmed arrived, and what the invoice claims is payable. RNV investigation is what happens inside three-way matching when the three documents do not line up cleanly the first time. The investigation succeeds when the three are reconciled and a voucher can be built; it fails when the discrepancy needs supplier action or a write-off decision.

Once the investigation completes, the resolution paths are bounded. Where the match is clean, post the voucher. Where the invoice or PO is wrong, raise a price or quantity dispute with the supplier and hold the voucher until the supplier issues a corrected invoice or credit memo. Where the receipt was posted in error, reverse it — and document why, because the reversal itself becomes an audit-trail item. Where only some lines are clean, post a partial voucher and leave the remainder open. Where the invoice will never arrive — the goods were returned, the supplier canceled, the receipt was for free samples — request a credit memo or write the receipt down with the approval level the policy requires. Each path leaves a record; skipping the documentation step is the most common reason audit trails fail in AP.

Aged RNV lines tend to repeat a small set of underlying causes: supplier-side invoicing backlogs, persistent PO-vs-invoice price mismatches the matching engine cannot auto-resolve, duplicate receipts posted against more than one PO line for the same physical delivery, receipts against goods later returned without a corresponding receipt reversal, and invoices paid through a manual channel that bypassed the PO-voucher flow entirely. Recognizing the pattern is part of the investigation — the first three of those causes have very different fixes from the last two, and treating them all as "missing invoice" wastes time.

Some lines do not resolve through investigation alone and need to move into a formal exception workflow. Where a price dispute is unresolved past a threshold, where a duplicate receipt needs a controller-level reversal, where a credit memo is overdue — these belong in an AP invoice exception management workflow with the right approvals, tracking, and aging escalation, not stuck in an AP clerk's mental backlog.

Month-End RNV: Aging, Audit, and How Lines Clear

At cutoff, the open RNV balance is a real, recognized liability and belongs on the balance sheet — the obligation to suppliers for goods or services already received but not yet matched into payable vouchers. The receipt is the recognition event, not the invoice.

The most informative single view of the balance for close and audit is its aging profile. Current and 30-day buckets are operationally normal: receipts ahead of invoices, invoices working through matching, the routine in-flight lag in any AP cycle. Lines aged 60, 90, and 120+ days signal something else — missing invoices, unresolved supplier disputes, duplicate receipts that were never reversed, or supplier obligations paid through some manual channel outside the PO-voucher flow that left the RNV line open even though the cash is already out the door.

External auditors typically focus on four things in this area. First, RNV reconciliation between the open-item report and the GL control account — the report and the balance must tie. Second, the aging profile compared against reasonable cycle times for the operation; what counts as reasonable varies by industry, supplier mix, and how invoice volume is concentrated, so universal tolerance thresholds are not useful here. Third, documentation for any aged lines being written down, accepted as known exceptions, or held for supplier dispute — auditors are looking for evidence each aged line has a deliberate disposition. And fourth, evidence the team is actively working the aging rather than letting it drift quarter over quarter.

Most lines clear in the normal course within 30 to 60 days. The invoice arrives, three-way matching succeeds, the voucher is created, RNV is debited, accounts payable is credited — the same journal directionality the opening section walked. Aged lines clear through the investigation work above, or, where the underlying transaction has been resolved another way and the RNV entry no longer reflects a real obligation, through accrual reversal with appropriate approval. Either route lands the line at zero and removes it from the report.

The cost of letting aged RNV drift is concrete. Stuck receipts distort cost of sales and inventory carrying value if the goods are sitting on the books with no payable behind them. Suppressed accounts payable understates current liabilities when invoices have been received but not vouchered into AP. Year-end clean-up becomes harder the longer aged lines are deferred, because supplier memory fades, source documents move, and the auditors who eventually look at the balance have less to work with. The practical implication is that RNV aging is best worked continuously through the AP cycle rather than addressed only at quarter-end or year-end.