Non-PO & Unexpected Delivery Triage

The problem this kills

A box lands on the dock. The packing slip says it's from a supplier you half-recognize, addressed to nobody in particular, and there's no purchase order number anywhere on it. Your receiving clerk can't post the receipt — your system won't accept goods without a PO — so the box gets shoved in a corner with a sticky note. A week later nobody remembers who ordered it, the supplier is chasing payment, and procurement is playing detective from a cold trail.

This happens more than anyone admits: a manager ordered directly, a sample arrived, a back-order shipped late under a closed PO, or somebody emailed a supplier instead of raising a requisition. Each one is a small fire, and right now you fight them by walking around asking "did you order this?" The slip gets lost, the receipt is delayed, the accrual is wrong, and the same person keeps doing the same end-run because nobody ever coached them.

This is exactly the kind of small, rules-based triage a tiny internal tool does far better than sticky notes and group chats — and you do not need to be a developer to build it.

What you'll build

A simple internal web tool for the dock and the procurement desk. A receiving clerk opens it on a phone or laptop, snaps a photo of the packing slip, and logs the basics — supplier, what came, how many, the carrier, the packing-slip number, and any clue about who probably ordered it. That creates a triage case and routes it to procurement automatically.

Procurement opens the case, searches your imported list of open POs for a likely match, and picks one of three dispositions: match to an existing PO, raise an after-the-fact (retroactive) requisition with a required written justification, or reject and return it. Nothing is accepted until a procurement reviewer approves the disposition — the clerk can't self-resolve. On approval, the tool records a linked receipt or a logged rejection, exports a clean CSV in the columns your system expects, and keeps a running, audited list of every mystery box — including a trend report of who keeps ordering off-process so you can coach the team.

What's inside the Implementation Plan

The plan is a single file you paste into an AI coding agent. It opens by interviewing you about your business — how non-PO deliveries reach you today, which ERP or system you receive goods in, the exact fields and naming on your packing slips and POs, your typical and peak volumes, your approval rules and dollar thresholds, and your nastiest edge cases — and then tailors the data model, the matching search, the validations, and every later step to your answers. This is a tool shaped around your dock and your procurement policy, not a generic template.

From there it walks the agent through the database schema, the clerk's mobile-friendly logging form with the packing-slip photo upload, the open-PO import and search, the procurement review-and-approve screen with the three dispositions, the duplicate guard so one physical delivery becomes exactly one case, and the CSV export. Every step ends with a ready-to-copy prompt. Because the whole thing runs on a CSV (or Google Sheet) of open POs in and a clean CSV out, you can build and use it this afternoon even with no live connection to your ERP.

The governance it includes (this is the point)

This decides whether goods get accepted and paid for, so it's built like it matters: login so only your team can use it, row-level security so you only ever see your own organization's deliveries, and a complete audit trail of every log, edit, disposition, approval, and export — who did what, and when. Nothing is accepted automatically: every non-PO delivery is a draft case until a procurement reviewer approves the disposition, and that approval is the hard human-in-the-loop gate before a receipt is recorded or goods are returned. Receivers cannot self-resolve their own cases. A duplicate guard on supplier + packing-slip number means the same physical delivery can't be logged or processed twice, and every retroactive requisition is flagged as a policy exception and rolled into a trend report.

Who it's for

Receiving staff and procurement teams who regularly get mystery boxes they can't post against a PO — and who are tired of chasing down who ordered what. If you can describe how a delivery reaches your dock and how procurement decides what to do with it, you can build this.

You've got this — open the plan, paste the first prompt, and let it interview you about your dock.