Record a receipt against a purchase order
Records physical receipt of goods against a purchase order, creating inventory receive
transactions and incrementing on-hand balances for each received line. Partial receipts are
supported; the PO transitions to status: partially_received and finally to received when
all lines are fully received.
Over-receipt tolerance (NEW-GAP-PO-RECEIVE-OVER-RECEIPT-ZERO-TOLERANCE-CONFLICTS-AP-5PCT,
2026-05-16): the receive cap is Math.floor(remaining * tolerance) where tolerance is
resolved per-entity as settings.po_overreceipt_tolerance (dock-side knob) -> fall through
to settings.ap_qty_tolerance (AP-side knob) -> default 1.05 (5%). Bodies whose
quantity_received + damaged_qty > cap reject with HTTP 400 over_receipt_blocked and an
envelope of { ordered, already_received, remaining, attempted, tolerance_pct, cap, hint }.
Industry parity: NetSuite Over-Receipt Tolerance / Acumatica Receipt Tolerance / SAP B1
Goods Receipt over-tolerance all expose a single tolerance % governing both dock + 3-way
match. Arcus exposes two knobs (dock falls through to AP) so entities can tighten dock
control without affecting 3-way match.
Idempotency (NEW-GAP-AP-PO-RECEIVE-IDEMPOTENCY-GUARD, 2026-06-15): the receive is a
financial mutation (inventory + GRNI + optional auto vendor bill). A server-side guard
dedups an identical retry (same PO + same line set: product / qty / damaged_qty) within a
120-second window and returns the original receipt with HTTP 200 + idempotent: true and
zero new side effects. A legitimately distinct follow-up partial (different qty / lines)
still creates a new receipt. You may additionally send a standard Idempotency-Key header
for cross-window safety.
Requires purchasing:write scope.
Authorizations
API key issued per entity via Settings > Developers > API Keys.
Each key carries scopes (e.g. orders:read, products:write).
Bearer token format: Authorization: Bearer ark_live_ent_Test keys use ark_test_ent_. Both are issued per entity
via Settings > Developers > API Keys.

