GRNI (Goods Received Not Invoiced)

GRNI, goods received not invoiced, is the population of purchase orders where the goods or services have arrived but the vendor's invoice hasn't. The name describes an account as often as it describes the population itself: many charts of accounts carry a GRNI or "accrued liabilities - received not invoiced" line that captures exactly this gap between receipt and billing.

The reason it gets its own line rather than waiting on the invoice is straightforward: a liability exists the moment the goods or services are received, not the moment a bill happens to arrive for them. Invoice timing is a vendor's administrative process, not an accounting event. A vendor that bills promptly and one that bills six weeks late create the same obligation on the same day; only the paperwork lands on a different one. Waiting for the invoice to record the liability means understating what the company owes for however long the vendor takes to invoice, which is exactly the kind of unrecorded liability a close is supposed to catch, not create.

This is also why three-way match and GRNI sit next to each other rather than in separate processes. A three-way match compares the purchase order, the receiving document, and the invoice before a payable is approved, and the receiving document is what proves the GRNI liability exists in the first place. A three-way match process that keeps a clean, current received-not-invoiced report has already done the hard part of the accrual: identified exactly which POs were received, at what quantity, and for what price. What is left is booking it. A process without that report is stuck estimating the same population instead of reading it off a list.

The mechanics of the accrual are simple once the population is right: debit the expense or asset the PO was for, credit accrued liabilities, for the value of goods or services received but not yet billed, then reverse the entry when the actual invoice posts so the real bill doesn't double up on top of the estimate. The estimate is usually the PO's unit price times the quantity confirmed received, which is more reliable than a guess precisely because it is backed by a receiving document rather than an approximation.

What actually breaks a GRNI accrual is a stale "received" or "invoiced" flag. An open PO report is a snapshot, and the moment an invoice gets keyed against a PO after that snapshot was pulled, the report's own word is wrong until it refreshes. Accruing off that flag without checking it against the AP register is the single most common way a GRNI accrual either double-books a liability that already got invoiced or misses one that just posted. The fix isn't a more careful read of the same report; it's cross-checking the open-PO population against the invoice register itself before anything gets proposed.

Related term: Three-Way Match

Related concept (not yet published as its own glossary entry): accounts payable.

Go deeper: AP Automation

Reading a GRNI population off a purchase-order report and cross-checking it against the AP register by hand, every close, is exactly the kind of volume work that eats hours without needing much judgment until the estimate itself. Adopt's agents match open POs against receipts and the AP register, propose the accrual with its basis stated and a reversal flag attached, and route only the genuine exceptions, a PO with no clear receipt, a price that doesn't tie out, to a Controller for approval. Sign up free.