Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Packing slip checker series ~6 min read

A packing slip checker on AWS for a few dollars a month

A pallet arrives. The driver wants a signature. The delivery note says twelve boxes and there are twelve boxes, so somebody signs, and eleven days later it turns out one of the boxes contained forty units instead of sixty. At that point the supplier’s position is that a signed delivery note says it was all there. This post walks through a small system built entirely around that ninety seconds at the door.

man in red jacket standing beside orange van during daytime
Photo by KAZEM HUSSEIN on Unsplash

Key takeaways

  • Three documents, not two: the order, the slip, and what is physically there.
  • The only moment a discrepancy can be proved is before the delivery note is signed.
  • The receiving interface has about ninety seconds and one hand available.
  • Nothing is auto-rejected and no claim is auto-filed.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: order, packing slip and physical count compared at receiptThree boxes across the top sit outside the AWS account. On the left, The purchase order: what we asked for. In the middle, The packing slip: what they claim they sent. On the right, The person receiving, holding a phone and a pen. Each connects by an arrow to the AWS account container below. Expected lines flow down into the account. Claimed lines feed in. A short list to check goes back out. Inside the AWS account are three components in a row. On the left, the Matcher, comparing order against slip before arrival. In the middle, the Receiving view, showing what to count and nothing else. On the right, the Recorder, capturing the discrepancy, the evidence and the timestamp. A note at the bottom says the middle box is the whole product, and everything else exists to make it short.AWS ACCOUNTThe purchase orderwhat we asked forThe packing slipwhat they claimthey sentThe person receivingholding a phone,and a penMatcherorder against slip,before arrivalReceiving viewwhat to count,and nothing elseRecorderdiscrepancy,evidence, timestampexpected linesclaimed linesa short list tocheckThe middle box is the whole product. Everything else exists to make it short.
Fig 1. Three things outside the account, three pieces inside it. The receiving view is where this system succeeds or fails, and its only job is to be short.
  • Database
  • Machine learning
  • Analytics
  • Front-end & mobile
  • People

Two documents agreeing is not a check

The standard implementation compares the packing slip to the purchase order and reports a match. It is easy, it produces a green tick, and it verifies nothing: both documents were produced by people looking at the same order, and neither of them has been inside the boxes.

The check that matters is the physical count, and it is expensive in the only currency the receiving bay has, which is attention. So the entire job of the first two components is to work out the shortest possible list of things a person actually needs to open and count, and then get out of the way.

What runs (the inside)

  • The matcher. Compares the order and the slip in advance and works out what needs physically checking. Part 2.
  • The receiving view. The ninety-second interface: a short list, a way to say “not what it says”, and a camera. Part 3.
  • The recorder. Captures the discrepancy with evidence and a timestamp before anybody signs. Parts 4 and 5.

One delivery, end to end

One delivery from packing slip to an annotated signatureA horizontal row of five boxes joined by arrows. Slip received: ahead of the van. Matched: two lines differ. Check list: open three of twelve boxes. Counted: one short by twenty. Annotated, then signed: in that order. A note says the last box's order is the difference between a claim and a disagreement.ONE DELIVERY, END TO ENDSlip receivedahead of the vanMatched2 lines differCheck listopen 3 of 12 boxesCountedone short by 20Annotated, then signedin that orderThe last box's order is the difference between a claim and a disagreement.
Fig 2. The same system as one line. Three boxes opened instead of twelve, and the signature happens after the annotation rather than before it.
  • Machine learning
  • Analytics
  • People

In plain words

The supplier emails a packing slip the day before. The matcher reads it and compares it with the purchase order: ten of the twelve lines match exactly, one is short by twenty units according to the slip itself, and one is a substituted product code.

When the pallet arrives, the person receiving does not see twelve lines. They see three: check the box with the short line, check the box with the substitution, and spot-check one line at random. Everything else is accepted on the slip, which is a deliberate and stated risk rather than an oversight.

The short line turns out to be short by forty rather than twenty. They tap the line, enter forty, photograph the open box and the label, and the system produces the wording to write on the delivery note. Then they sign, with that annotation on it, and the driver takes their copy of the same words.

Design rules that shaped every decision

  • Never present twelve lines to somebody with ninety seconds. Present the ones that matter.
  • Annotate the delivery note before signing. Afterwards is a different legal position.
  • A photograph with the label in frame is worth more than any number of typed notes.
  • Nothing is auto-rejected. Refusing a delivery is a commercial decision.
  • Record what was seen, not what it means. Interpretation comes later, from a person.
  • Accepting a line on the slip is a stated decision, recorded as one.

Why this shape

Goods receipt errors are usually blamed on carelessness in the warehouse, and the diagnosis is almost always wrong. The person receiving is doing an unpaid documentary task, under time pressure, with a driver waiting, using a system designed by somebody sitting down.

So the design treats the ninety seconds as the binding constraint and spends everything it has — pre-matching, prioritisation, one-handed interaction, photographs instead of typing — on making that window productive. The rest is bookkeeping.

The next four posts walk through each piece: how the three documents get compared, how a discrepancy is recorded at the door, what happens to over- and under-shipments, and how individual discrepancies become a pattern worth acting on. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts