Skip to main content

Get Cost Change

GET 
/api/cost-changes/:costChange

Returns one cost change set with its staged lines (one per FIFO layer: unit cost before and after, units on hand and already consumed at staging time, the original receipt date), its decision history, the restate-versus-prospective impact comparison (impact, the same payload as Get Impact Preview) and what_changed - every cost document on the originating purchase order, dated both by document date and by the day it was entered, so the delta can be read against its sources. what_changed is null when the trigger cannot be traced back to a purchase order.

Required scope: inventory:read

Grant this scope to your token under Settings → Developer → Personal Access Tokens.

restate_blocked_reason is null when restate is a real option, or the sentence explaining why it is refused when the original receipt months are behind the accounting lock date.

Authentication: Requires Bearer token (inventory scope).

Path params:

  • costChange: Cost change set ID

Each cost change also reports what it MOVED, by cost category. composition_movement on the change is the roll-up across its lines, and each line carries composition_before, composition_after and its own composition_movement. The trigger names the document that set the recalculation off, which is not always the document that caused the money to move — re-costing a purchase order picks up any charge on it that had not yet been capitalised. Comparing the movement's categories against the charges the trigger document actually carries is what tells the two apart. Empty on changes recorded before the composition was captured.

warnings[] — {code, message} entries surfaced on the detail view. overlaps_vendor_credit means an authorized vendor credit already reduced the cost of goods this purchase order line or invoice edit is reducing again — a likely double count. It carries vendor_credit_id, vendor_credit_number, vendor_credit_line_id and purchase_order_line_id, and is only raised for edits dated on or after the credit; it warns and never blocks.

recorded is null until the change is applied. For an APPLIED change impact reports what was actually booked rather than a re-run of the preview against today's layers: recorded is {resolution, on_hand, consumed, total} (the resolution that was applied, the amount booked to Inventory for units still on hand, the amount booked to cost of goods sold for units already consumed, and their sum), periods carries those booked figures per month on the applied side (restate_* or prospective_*), preview_stale is false and downstream is null (the cascade into stock made from these layers already ran on apply). Passing prospective_date on an applied change is a what-if and still returns the live preview with recorded null.

held_because: for a change waiting for review, one plain-language line saying why it was held (the document type's rule, the significance threshold, or which always-review guardrail applied). Null once the change is decided.

Request​

Responses​

OK

Response Headers
    Content-Type