What is a stock count reconciler?

A small serverless system that takes a physical stock count — a scan or a sheet submitted by staff — and reconciles it against the system of record line by line. For each item it computes the variance between the counted quantity and the system quantity, asks a model for the likely cause of any gap, and queues material variances for a manager’s sign-off. Approved adjustments are posted back to inventory with a full audit trail. It never moves stock on its own; a human approves every adjustment. It is distinct from a reorder bot — this one reconciles what you have, it does not buy more.

How much does it cost to run?

About $2.20/month at typical small-business volume (around 2,000 SKUs counted each month, of which a few percent come back as variances). The fixed cost is dominated by a single Secrets Manager secret at $0.40/month. The variable cost is one small Bedrock Haiku 4.5 call per variance line to suggest a likely cause; the variance arithmetic itself is plain Python and costs almost nothing. At ten times the volume — around 20,000 SKUs a month — the bill lands around $13.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the approve/reject buttons, EventBridge (count-submitted events plus Scheduler for periodic count reminders and a daily aged-variance sweep), DynamoDB on-demand for inventory, count sessions, and the adjustments audit, S3 for uploaded count sheets, SES for manager notifications, SQS with a dead-letter queue, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to suggest a likely cause. No API Gateway, no NAT Gateway, no always-on compute, one region.

How does it work out a likely cause for a variance?

Plain code computes every variance first — counted quantity minus system quantity, the percentage, and the value of the gap. For each material variance the system builds a small evidence bundle: the size and direction of the gap, recent sales for that SKU, the last receiving against it, and when it was last counted. That bundle goes to one Bedrock Haiku 4.5 call, which returns a ranked likely cause from a fixed list — shrinkage, miscount, unrecorded sale, or receiving error — with a one-line rationale. The cause is a label on a number the code already computed; the model never decides the number.

Sparingly, and only to suggest causes. The model never moves stock. The variance arithmetic — counted versus system, the percentage, the value, whether it crosses the materiality tolerance — is all plain Python with no model in the loop. Bedrock Haiku 4.5 fires once per material variance to put a likely-cause label on the gap, and once a month to write a short narrative summary. The reconciliation itself never depends on a model.

Can it adjust inventory on its own?

No. The reconciler only ever proposes. Variances inside tolerance are logged but post nothing. Material variances are queued for a manager, who sees the counted quantity, the system quantity, the gap, the suggested cause, and two buttons: Approve (post the adjustment) or Reject (discard it, count holds). Only an approved adjustment is written back to inventory, and every action — queued, approved, rejected, posted — is recorded in the stkr-adjustments table with a timestamp, the user, and a before-and-after snapshot.

Series · 7 parts Published June 27, 2026

Stock count reconciler

A physical stock count almost never matches the system of record, and the gap is where money quietly leaks — shrinkage nobody logged, a sale that never rang through, a delivery counted twice at the dock. This is a small serverless system that takes a physical count, compares each counted line against the system quantity, works out the variance, and asks a model for the likely cause — then queues every material gap for a manager’s sign-off before a single adjustment is posted. The arithmetic is plain code; the model only ever suggests a cause, it never moves stock. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A stock count reconciler on AWS for a few dollars a month

The whole system on one page — a count capture, a variance-and-cause engine, and an approval-and-write-back piece, plus the four likely causes every flagged gap is labelled with.
02

How a count gets captured

How a count comes in — staff submit a scan or a sheet, it lands in S3, an event fires, and the capture Lambda normalises it into clean counted lines tied to a count session, ready to reconcile.
03

How a variance gets found

How a variance gets found — the engine joins each counted line to the system quantity, computes the gap in units, percent, and value, and decides whether it crosses the materiality tolerance. Plain code, no model.
04

How a likely cause gets suggested

How a likely cause gets suggested — for each material variance the system builds a small evidence bundle and asks one Bedrock call to pick a cause from a fixed list, with a one-line rationale. The model labels; it never moves stock.
05

How an adjustment gets approved

How an adjustment gets approved — material variances are queued, a manager gets an email with the gap and the suggested cause and two buttons, and only an approved adjustment is posted back to inventory with a full audit trail.
06

What the stock count reconciler costs

A few dollars a month at SMB volume. The variance arithmetic is free; the cost is one small Bedrock call per variance line and a single Secrets Manager secret. Costs at three volumes, and what doesn’t cost anything.
07

Engineering reference: the stock count reconciler architecture

The same system drawn purely for engineers — the full architecture diagram, every Lambda and Function URL, the EventBridge rules and schedules, the DynamoDB tables and key schemas, S3, SES, IAM scopes, the Bedrock model id, and the region.

What is a stock count reconciler?: A small serverless system that takes a physical stock count — a scan or a sheet submitted by staff — and reconciles it against the system of record line by line. For each item it computes the variance between the counted quantity and the system quantity, asks a model for the likely cause of any gap, and queues material variances for a manager’s sign-off. Approved adjustments are posted back to inventory with a full audit trail. It never moves stock on its own; a human approves every adjustment. It is distinct from a reorder bot — this one reconciles what you have, it does not buy more.
How much does it cost to run?: About $2.20/month at typical small-business volume (around 2,000 SKUs counted each month, of which a few percent come back as variances). The fixed cost is dominated by a single Secrets Manager secret at $0.40/month. The variable cost is one small Bedrock Haiku 4.5 call per variance line to suggest a likely cause; the variance arithmetic itself is plain Python and costs almost nothing. At ten times the volume — around 20,000 SKUs a month — the bill lands around $13.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the approve/reject buttons, EventBridge (count-submitted events plus Scheduler for periodic count reminders and a daily aged-variance sweep), DynamoDB on-demand for inventory, count sessions, and the adjustments audit, S3 for uploaded count sheets, SES for manager notifications, SQS with a dead-letter queue, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to suggest a likely cause. No API Gateway, no NAT Gateway, no always-on compute, one region.
How does it work out a likely cause for a variance?: Plain code computes every variance first — counted quantity minus system quantity, the percentage, and the value of the gap. For each material variance the system builds a small evidence bundle: the size and direction of the gap, recent sales for that SKU, the last receiving against it, and when it was last counted. That bundle goes to one Bedrock Haiku 4.5 call, which returns a ranked likely cause from a fixed list — shrinkage, miscount, unrecorded sale, or receiving error — with a one-line rationale. The cause is a label on a number the code already computed; the model never decides the number.
Does it use AI?: Sparingly, and only to suggest causes. The model never moves stock. The variance arithmetic — counted versus system, the percentage, the value, whether it crosses the materiality tolerance — is all plain Python with no model in the loop. Bedrock Haiku 4.5 fires once per material variance to put a likely-cause label on the gap, and once a month to write a short narrative summary. The reconciliation itself never depends on a model.
Can it adjust inventory on its own?: No. The reconciler only ever proposes. Variances inside tolerance are logged but post nothing. Material variances are queued for a manager, who sees the counted quantity, the system quantity, the gap, the suggested cause, and two buttons: Approve (post the adjustment) or Reject (discard it, count holds). Only an approved adjustment is written back to inventory, and every action — queued, approved, rejected, posted — is recorded in the stkr-adjustments table with a timestamp, the user, and a before-and-after snapshot.

All posts

Frequently asked questions

Other series