No Origin, No Deduction: Linking Negative Stock Adjustments to Their Cause

A stock level that goes down with no stated reason is hard to explain later. This article proposes a rule for an inventory feature: a negative adjustment is accepted only when it points to an origin you can look up. It is a software design idea and not accounting advice; how your business must record stock is a separate question for the people responsible for it.

Primary artifact: the adjustment linkage acceptance matrix

Every incoming adjustment is classified by three questions: is the quantity negative, is an origin reference present, and does that reference resolve to a record in a usable state.

Positive quantity: outside this rule. Pass it to whichever separate rule governs additions.
Negative, no reference: reject.
Negative, reference present but not found: reject.
Negative, reference found but its record is closed or belongs to a different item: hold for human review.
Negative, reference found, open, and for the same item: accept.

The origin record might be a counting session, a damage report, a transfer, or a sale. Your own list of allowed origin types should be written down; this article invents none.

Decision branches

Branch A: the request comes from a person typing in a form. Show the reason for rejection in plain words and keep what they typed, so they can add a reference and submit again themselves.

Branch B: the request comes from an automated integration. Return a clear rejection code. Do not let the sender repeat the same payload on a timer; a rejection is not a transient failure. If the sender could not tell whether an earlier attempt landed, it should check by its own idempotency key before sending anything, and a local flag alone is not proof of delivery.

Branch C: a bulk file. Judge each line separately and report per line, so one bad line does not hide the rest or block them silently.

Worked hypothetical

Five adjustments arrive in one batch for item X:

minus 3, references counting session C-1, which exists, is open and covers item X. Accept.
minus 2, no reference. Reject.
plus 4, no reference. Outside this rule, passed on.
minus 1, references R-99, which cannot be found. Reject.
minus 5, references a transfer record that is already closed. Hold.

Totals: 5 submitted, 1 accepted, 1 passed on, 2 rejected, 1 held. 1 + 1 + 2 + 1 equals 5. Only line 1 changes the level, so the level drops by 3. The held line changes nothing until a reviewer decides, and the reviewer's decision, with a name and time, is recorded beside it.

Stop conditions

Stop applying a batch if the same origin reference is used by more adjustments than the origin record's stated quantity allows. The rule for that limit belongs to the owner of the origin record.
Stop and escalate if rejected lines rise sharply after an integration change.
Never fill in a missing reference automatically with a placeholder or with the most recent session.
Never auto repeat a write whose result is uncertain.

Proposed acceptance tests (not yet performed)

Submit a negative adjustment with no reference and expect a rejection with a stated reason.
Submit one with a reference to a nonexistent record and expect rejection.
Submit one with a valid open reference and expect acceptance and a visible link both ways.
Submit one referencing a record for another item and expect a hold.
Submit a positive adjustment without reference and expect it to bypass this rule.
Submit the batch above and compare the totals to 1, 1, 2, 1.
Resend an accepted line with the same key and expect no second deduction.

A passing run shows the rule behaves as specified in those cases; it says nothing about whether the stock figures themselves are right.