Fix NetSuite Quantity Billed Showing Zero

Your saved search keeps listing every line on the purchase order as zero quantity billed, even when only one line still needs billing. The cause is not your formula. You built the search at the wrong record.

When you start a Transaction Search with Type = Item Receipt, NetSuite evaluates {quantitybilled} against the item receipt line. An item receipt does not carry billed quantity. That accumulator lives on the purchase order line. So every IR line returns zero, and your {quantityshiprecv} > {quantitybilled} formula flags the whole PO as under-billed.

The fix is to start at the purchase order, where both {quantityshiprecv} and {quantitybilled} are native line fields.

Why the Item Receipt Is the Wrong Starting Point

An item receipt records what physically arrived. It has no knowledge of the vendor bill that comes later. The {quantitybilled} field on a receipt line is not populated from the related PO, so it reads as empty or zero.

Your criteria also join to the PO with Created From: Type is Purchase Order. That join gives you the PO header, not the PO line accumulators. You are comparing a receipt-line quantity against a PO-header field that does not aggregate per line the way you expect.

Starting at the PO changes everything. The PO line holds {quantityshiprecv} (shipped or received) and {quantitybilled} side by side. You can subtract them directly to find lines that were received but not yet billed. This mirrors the Purchasing and Receiving Guide explanation of how NetSuite tracks received and billed quantities as separate steps.

Build the Search from the Purchase Order

Create a new Transaction Search (Reports > New Search > Transaction Search) and set these criteria:

The Main Line = False and Tax Line = False filters strip out the PO header row and any tax lines so you only evaluate item lines. The formula returns 1 only when received quantity exceeds billed quantity on that specific line.

Add these results columns:

Now each row shows one PO line with its received and billed amounts in the same row. A line with quantityshiprecv of 10 and quantitybilled of 7 appears with a 3-unit gap. A fully billed line drops out of the results entirely.

List the Receipts and Bills for Each PO Line

The PO-based search gives you the comparison, but it does not show which item receipts and vendor bills make up those quantities. To see the document numbers, use the joins available on the PO line.

Add these result columns:

• Fulfilling/Receiving Transaction Fields... > Document Number for the item receipts
• Billing Transaction Fields... > Document Number for the vendor bills

One catch: if a PO line has multiple item receipts or multiple bills, the search returns one row per linked transaction. A line with two receipts and one bill produces two rows, with the same PO-line data repeated.

To collapse that into a single comma-separated list, use a Summary result with the Maximum function on {tranid} combined with NS_CONCAT on the joined document number. You can keep the PO line fields grouped and summarize the receipt and bill document numbers. That gives you one clean row per PO line with a list of the IRs and bills attached.

A Faster Built-In Option

If you do not need the full saved-search flexibility, check the native Purchase Order History report at Reports > Purchases > Purchase Order History. It is already a three-way purchasing report that ties the PO, the item receipt, and the vendor bill together on one view. You can customize its filters and columns without writing a formula.

The saved search is still the right tool when you want the output as a CSV, a scheduled email, or a dashboard portlet that flags only the under-billed lines. The report is the quick look; the search is the repeatable control.

What Trips People Up

Two details cause most of the confusion here.

First, {quantityshiprecv} is the shipped-or-received quantity on the PO line. For a purchase order, this is the received amount. You do not need a separate {quantityreceived} field for this comparison, though both exist on the PO item sublist.

Second, the Closed = False filter matters. Once a PO is fully billed or closed, its lines are removed from the billing queue. If you leave the filter off, closed POs with a lingering difference can still appear, which makes your AP review noisier than it needs to be.

Reviewing the Output Before Posting

The real value of this search is catching discrepancies before a vendor bill posts. When you see a PO line where quantityshiprecv exceeds quantitybilled, the vendor has not billed for goods you already received. That is a timing difference, not necessarily an error. When quantitybilled exceeds quantityshiprecv, you are paying for goods not yet received, which is the condition your auditors will question.

For the under-billed case, open the PO and confirm the open line is still in the billing queue. If the vendor bill was entered against a different PO line or a standalone bill, the mismatch shows up here as a line that never closes. That is exactly the kind of discrepancy that surfaces during a check run, when the AP clerk has to decide whether to pay a bill that does not match the receipt.

If you want to flag these mismatches on a regular schedule, save the search and set it to email the results to the AP team. That turns a manual review into a standing control, and it keeps the vendor bill variance discussion out of the close cycle.