How an adjustment gets approved

Key takeaways

Each material variance is queued and emailed to the approver for its location, with the gap and the suggested cause.
Two buttons, two Function URLs: Approve posts the adjustment; Reject discards it and the count line stands.
An approved adjustment writes to stkr-inventory atomically, guarded against a double-tap or a stale snapshot.
Every action — queued, approved, rejected, posted — lands in stkr-adjustments with a before-and-after snapshot.
A daily sweep re-surfaces anything left unactioned, and a monthly summary reports the split of causes. No stock moves itself.

From a flag to a person

A material variance with a suggested cause is the end of the automated part and the start of the human one. The approval piece takes each one, works out who should decide it, and puts it in front of them with everything they need to decide in one glance — and nothing they don’t.

The who comes from the rules doc: an approver per location. The fixings aisle belongs to Priya; the paint aisle to someone else. Routing by location rather than blasting every variance to one inbox keeps each manager looking only at their own stock, and keeps the sign-off close to the person who can actually walk over and recount the rack.

The email carries the full picture: SKU and name, location, counted quantity, system quantity, the gap in units, percent, and value, the suggested cause with its one-line rationale, and two buttons — Approve and Reject. For our bolt line: “BOLT-M6-50 — M6 bolts 50 mm, fixings aisle. Counted 432, system 480. Short 48 units (−10%, −£16.80). Likely shrinkage: sustained shortage, no recent receiving, normal sales. [Approve] [Reject].” Quiet hours from the rules doc hold a notification back until the morning, so a count finished at 9 p.m. doesn’t buzz anyone’s phone.

Two buttons, two Function URLs

The buttons are Lambda Function URLs — no API Gateway. Each is a signed, single-purpose link tied to that one variance, and tapping it lands on the stkr-approve Lambda.

Approve means “the gap is real, post it.” The Lambda writes the adjustment to stkr-inventory — in our case bringing the system quantity from 480 to 432 — and records the action. This is the only path that moves stock, and a person is always on the end of it.
Reject means “don’t post this.” The count line stands as a recorded observation, but the system of record is left untouched. A manager rejects when they suspect a miscount and want a recount first, or when they know the cause and will handle it outside the system.

There’s deliberately no third button. The bill matcher had a Query action because there was a supplier to write back to; a stock count has no counterparty to query, only a shelf to recount. If a manager wants a recount, they reject and open a fresh session — which keeps the audit trail honest, because the new count is its own dated session rather than an edit to the old one.

Fig 5. A queued variance is emailed to the right approver. Approve posts the adjustment to inventory atomically and writes an audit row; Reject discards it and leaves the system untouched. Both are logged. A daily sweep chases stragglers and a monthly summary reports the causes.

Posting it safely

Posting an adjustment is the one moment a number in the system of record actually changes, so it’s the most carefully guarded step in the whole system.

It’s atomic and idempotent. Approving writes the new quantity to stkr-inventory as a single conditional update keyed on the variance staying in its queued state. If the manager taps Approve twice, or forwards the email and a colleague taps it too, the second write finds the variance already approved and does nothing. No adjustment is ever applied twice.
It checks the snapshot is still current. The update also confirms the system quantity hasn’t moved since the count snapshot. If stock changed between the count and the sign-off — a delivery booked in, a sale rung through — the post is held and the variance is re-surfaced for a fresh look, rather than stamping a stale number over a live one.
It writes the trail before it’s done. Every action writes a row to stkr-adjustments: the timestamp, the SKU, the action (queued, approved, rejected, posted), the user who did it, the suggested cause, and a before-and-after snapshot of the quantity. Audit a stock figure next year and you can reconstruct exactly who changed it, when, from what to what, and why.

Nothing quietly ages out

Two scheduled jobs keep the queue honest, both driven by EventBridge Scheduler. A daily aged-variance sweep re-surfaces any material variance still sitting unactioned past its due window, so a gap doesn’t quietly age out because the one manager who could approve it was on leave. EventBridge Scheduler also fires the periodic count reminders — nudging a location that hasn’t been counted in too long, since a reconciler only works if counts actually happen. And a monthly summary writes a short narrative with one larger Bedrock call: lines counted, value caught in variances, the split across the four causes, and the SKUs that keep coming back short — the view that turns one-off sign-offs into a picture of where stock is actually leaking.

Why this shape

Routing is per location, so each manager sees only their own stock and the sign-off sits next to the shelf.
Two buttons, not three — a stock count has a shelf to recount, not a counterparty to query. A recount is a fresh, dated session.
Posting is atomic and idempotent, so a double-tap or a forwarded link can never apply an adjustment twice.
A stale snapshot holds the post rather than overwriting a number that moved since the count.
Every action is logged with a before-and-after snapshot, so any stock figure is auditable long after the fact.
A daily sweep and scheduled reminders keep both the queue and the counts themselves from quietly lapsing.

That completes the walk through the system. The next post puts a price on all of it: what the stock count reconciler actually costs to run, where the dollars go, and how the bill scales.

All posts