Skip to Content

GRNI Reconciliation

21 December 2025 by
GRNI Reconciliation
Davin Fowler

Over the years, almost every new customer I take on who buys and sells stock asks me the same question: "Can you give us a reconciliation for our GRNI account?"

The GRNI account—variously called Inventory Received Not Billed (IRNB), Accrued Purchases, or Stock Accrual—sits at the heart of the purchase-to-pay cycle. When you receive goods, NetSuite credits GRNI. When the bill arrives, it debits GRNI. The balance represents receipts awaiting invoices, plus any variances.

NetSuite provides no standard report to reconcile this account back to the underlying transactions. So I've built various saved searches over the years to fill this gap. Let me walk through an example that works for accounts using standard costing.

The Core Challenge

At the heart of GRNI reconciliation is the relationship between purchase orders, item receipts, and vendor bills.

The challenge is that a single purchase order line might be received across multiple shipments and billed across multiple invoices, arriving weeks or months apart. We need a search that gathers all of these and groups them correctly.


Example GRNI Reconciliation Search (Standard Costing)


This saved search works if you are using standard costing. The approach relies on a key insight: the GRNI posting on an item receipt is recorded as an aggregate figure, not itemised by line. You can't directly query the GRNI account on receipts and get a per-item breakdown.

But there's a workaround. On a standard cost receipt, the other side of the transaction. The Stock account and Purchase Price Variance (PPV) account—are itemised. And since it's double-entry bookkeeping, the Stock + PPV amounts will always equal the GRNI credit.

So instead of querying the GRNI account on receipts, we query the Stock and PPV accounts. This gives us the GRNI value broken down by item.

Criteria Tab

The search needs to capture two distinct sets of transactions:


Group 1 finds any transaction posting directly to the GRNI account (117) that isn't an item receipt. This captures vendor bills, vendor credits, and journal entries—the latter being important as these are often used for variance write-offs.

Group 2 finds item receipts created from purchase orders, but instead of looking at the GRNI account, it looks at accounts 109 and 111 (Stock and PPV). These itemised postings give us the GRNI amount per item.

Why exclude receipts from Group 1? Because the GRNI credit on a receipt is posted as an aggregate total. If we included it, we'd double-count and lose the per-item breakdown.

Summary Tab

The summary tab adds a crucial filter: only show results where the calculated GRNI balance is not zero.

The formula handles each transaction type differently:

  • Item Receipts with no applied transaction: negate the amount (these are credits to GRNI)
  • Vendor Bills linked via "Order Bill" or with no link type: include the amount (these are debits to GRNI)
  • Everything else: include the amount as-is

By filtering to SUM ≠ 0, we only see purchase orders that have an outstanding balance—either receipts awaiting bills, or variances that haven't been cleared.


Results Columns

The results tab groups transactions by purchase order and item, then shows the breakdown:

ColumnPurpose
PO Number / DateIdentifies the source purchase order
ItemGroups by item within the PO
SupplierShows the vendor name
PO StatusHelps identify if the PO is still open
Item ReceiptSum of receipt amounts (via Stock/PPV)
BillSum of bill amounts to GRNI
Bill CreditSum of vendor credit amounts
Journal EntrySum of journal adjustments
RevaluationSum of FX revaluation entries
GRNI BalanceNet balance (the GRNI amount)


Limitations of This Approach

This search works well for standard costing, but it has limitations:

  • Costing method dependent: The Stock + PPV proxy only works for standard costing. Average or FIFO costing requires a different approach.
  • Aggregation by item: If a purchase order has multiple lines for the same item, they'll be grouped together and you lose the line-level distinction.
  • No receipt-to-bill matching: The search shows totals, but can't tell you which specific receipt matches which specific bill.