Acumatica Purchase Orders — Receipt and Bill

The Acumatica procure-to-pay flow is four documents that hand off to each other: a Purchase Order commits to buy, a Purchase Receipt records what physically arrived, an AP Bill records what the vendor charged, and a payment settles it. Three-way matching is the discipline that makes sure the PO, the receipt, and the bill agree before anything posts — and understanding where each quantity and amount lives is what lets you catch a mismatch before it becomes a payment you cannot claw back.

The four documents and how they link

Each document references the one before it. The Purchase Order (screen PO301000) holds ordered quantities and agreed prices. The Purchase Receipt (PO302000) records received quantities against PO lines and, on release, updates inventory and creates the accrual to the PO/PR accrual account. The AP Bill (AP301000) is entered against the receipt (or directly against the PO), and releasing it moves the liability into Accounts Payable. The link chain — PO line → receipt line → bill line — is what three-way matching walks.

Purchase Order    ordered qty, agreed price
      │
Purchase Receipt  received qty  → Dr Inventory / Cr PO accrual
      │
AP Bill           billed qty/amt → Dr PO accrual / Cr AP
      │
Payment           settles the AP balance

Three-way matching, concretely

Three-way matching compares three numbers per line: quantity ordered (PO), quantity received (receipt), and quantity/amount billed (bill). The bill should not exceed what was received, and the price should match the PO within tolerance. Acumatica enforces this when matching is enabled on the vendor or the AP setup: a bill that exceeds tolerance goes on hold for review rather than posting. That hold is the whole point — it stops an overbill or a duplicate invoice at the last gate before money moves.

Configuring matching tolerances

Tolerances live in AP and PO preferences: you set how much a billed price or amount may deviate from the PO before the bill is held. Setting tolerance to zero means every rounding difference blocks a bill, which frustrates AP clerks; setting it too loose defeats the control. Pick a small percentage or absolute amount that reflects real vendor variance, and let the hold catch the genuine outliers.

Vendor returns and corrections

When goods go back, you do not delete the receipt — you enter a return. A Purchase Return (a receipt of type Return) reverses the inventory and accrual entries for the returned quantity, and a debit adjustment / credit memo on the AP side reduces what you owe the vendor. Keeping returns as their own documents preserves the audit trail: the original receipt still shows what arrived, and the return shows what left, so the net matches reality.

Reacting to the flow in code

When you need custom validation — say, block releasing a receipt if the PO is on a credit hold — hook the release process rather than the UI. The receipt lives on POReceipt/POReceiptLine and the graph is POReceiptEntry. A RowPersisting or an override on the release action lets you enforce a rule across every entry path, API included.

public class POReceiptEntryExt : PXGraphExtension<POReceiptEntry>
{
    protected void _(Events.RowPersisting<POReceipt> e)
    {
        var doc = e.Row;
        if (doc == null || doc.Released == true) return;

        // Block release when the linked vendor is on hold.
        var vendor = Vendor.PK.Find(Base, doc.VendorID);
        if (vendor?.Status == BAccount.status.Hold)
            throw new PXException(
                "Cannot release a receipt for a vendor on hold.");
    }
}

Wrapping up

Procure-to-pay in Acumatica is disciplined precisely because it is four linked documents with an accrual account in the middle. Enable three-way matching with sensible tolerances so overbills and duplicates land on hold, reconcile the received-not-billed accrual at close, and keep returns as their own documents. Do that and the AP balance you pay is always the one you actually agreed to and received.