Process and control
Partial receipt, partial return and PO close: what evidence should remain?
Keep ordered, accepted, returned, invoiced and short-closed quantities distinct with reasons and decision ownership.
If a PO orders 20 units, receives 15 and the supplier later confirms the remaining 5 will never ship, do not simply edit the original order to 15. That erases the evidence that the initial commitment was 20 and was later short-closed.
This article uses ERPNext purchasing documents as an implementation example, not a requirement that every organisation adopt the same document names or states.
Keep ordered, received, accepted, rejected and returned quantities distinct
Goods can physically arrive but fail inspection. Separate received, accepted and rejected amounts instead of forcing received = ordered. ERPNext Purchase Receipt supports accepted and rejected warehouses and updates pending quantity against the Purchase Order.
Clear quantities let purchasing know what is still expected, warehouse know what is usable and accounting compare invoices with actual receipt without relying on memory.
References: [1]
A partial return should reference the original receipt
If 15 units were received and two are later found defective, create a return referencing the original receipt with quantity, reason, evidence and date. Do not rewrite the receipt from 15 to 13 because that hides the fact that goods first entered and were later returned.
ERPNext Purchase Receipt can create Purchase Returns after submission and supports rejected-item return flows. The useful principle is event lineage rather than historical overwrite.
References: [1]
Short-close the remaining commitment when it will not be fulfilled
If the supplier confirms the remaining five units will not ship, an authorised role should short-close the balance with evidence such as supplier confirmation. Preserve the original ordered amount in history.
ERPNext documents Closed/short-closing behavior for cases such as ordering 20 but closing at 15 when the remaining amount will not be received or billed. The important principle is that close is a decision, not retroactive editing of the original fact.
References: [1]
Compare invoice quantity and rate with the relevant receipt and order
If the supplier bills 20 while only 15 were accepted, open an exception rather than changing receipt data to match the invoice. ERPNext Purchase Invoice can be created from Purchase Orders or Purchase Receipts and exposes accepted quantity, rate, UOM and linked rows for review.
Partial billing should remain distinct from pending receipt because “not yet billed” and “not yet received” describe different states.
References: [2]
Closing evidence should explain every quantity difference
Before closing, reconcile ordered, accepted, returned, invoiced and cancelled/short-closed quantities and list remaining exceptions. Any imbalance should point to a shipment, credit note, return confirmation or approval that is still pending.
UAT should include partial receipt, rejection at receipt, later return, partial invoice and short-close rather than testing only the happy path.
A practical starting checklist
- Separate ordered/received/accepted/rejected/returned quantities.
- Reference the original receipt for returns and keep the reason.
- Use authorised short-close instead of rewriting original order quantity.
- Review invoice quantity, rate and UOM against receipt/order.
- Test partial receipt, rejection, return, partial billing and short-close.
Apply it to your business
A traceable purchasing cycle does not force every number to match. It preserves each event and explains differences through explicit state, reason and evidence.
References
- Frappe. (n.d.). Purchase Receipt. Retrieved October 1, 2026.
- Frappe. (n.d.). Purchase Invoice. Retrieved October 1, 2026.
Numbered references support the attributed statements. Scenarios and recommendations are Linda’s examples, not verified client outcomes.
This article provides process-design guidance and illustrative examples, not an accounting, tax or legal determination or certification of every software module. Apply it with regard to your business, permissions and actual system scope.