Series · 7 parts Published May 31, 2026

Vendor onboarder

A serverless onboarder that gets a new supplier set up cleanly. It collects the details and documents you need from a new vendor — bank details, tax form, insurance certificate — checks each document is present and not expired, chases anything missing, and hands a complete, verified vendor file to the owner to approve before the vendor is added. Nothing is approved automatically; a human signs off. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

  1. 01

    A vendor onboarder on AWS for a few dollars a month

    The whole system on one page — an invite piece, a document checker, and a chase-and-approve piece, plus the four states every vendor file moves through.

  2. 02

    How a vendor gets invited

    An owner starts a vendor in three ways — a quick form, a forwarded email from the supplier, or a row in the Drive sheet. Each one creates a vendor folder and sends a private upload link.

  3. 03

    How a vendor document gets checked

    An uploaded file is read once: Textract pulls the text, Haiku 4.5 reads the fields, plain Python decides present-or-missing and not-expired, and a person confirms before any item counts as done.

  4. 04

    How a vendor gets chased for missing items

    A daily tick looks at what each vendor still owes, picks one of four moves, and sends a reminder that lists only what is still outstanding — nudge, follow-up, escalate, or done.

  5. 05

    How a vendor file gets approved

    When the file is complete, the owner gets one message with the whole file and three actions: approve (write to the system of record), request a fix, or reject. Nothing is added without a human tap.

  6. 06

    What the vendor onboarder costs

    A couple of dollars a month at SMB volume. The chase tick calls no model; Textract and Bedrock fire only when a vendor actually uploads a document.

  7. 07

    Engineering reference: the vendor onboarder architecture

    Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the SES inbound rule set, EventBridge Scheduler config, and the DynamoDB schemas.

What is a vendor onboarder?
A small serverless system that gets a new supplier set up cleanly. It collects the details and documents you need from a new vendor (bank details, tax form, insurance certificate), checks each document is present and not expired, chases anything missing on a polite schedule, and hands a complete, verified vendor file to the owner to approve before the vendor is added. Nothing is approved automatically; a human signs off.
How much does it cost to run?
About $2.20/month at typical small-business volume (around 8 new vendors a month). The fixed cost is essentially zero. The variable cost is dominated by reading uploaded documents: Textract reads each PDF and Bedrock Haiku 4.5 pulls the fields, and both fire only when a vendor actually uploads something. At around 40 new vendors a month the bill lands near $9.
Which AWS services does it use?
Lambda (Python 3.14, arm64) with Function URLs for the upload page and the approve button, EventBridge Scheduler for the daily chase tick, DynamoDB on-demand, S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) plus Textract for reading uploaded documents. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.
Where does the vendor file live?
Each vendor is one folder in S3 (the documents) plus one row in a DynamoDB table (the checklist status). The owner-facing view is a Google Sheet that a small drive-sync Lambda keeps current. One row per vendor with name, contact, the status of every required document, and a link to the file. Nothing goes into your accounting system until the owner approves.
Does the onboarder use AI?
Sparingly. The chase schedule and the present/expired checks are plain Python — no AI. Bedrock Haiku 4.5 fires only when a vendor uploads a document, to read the fields off it (the tax-ID on a W-9, the expiry date on an insurance certificate) so a human can confirm them. The daily chase tick calls no model at all.
How does it chase a vendor without being annoying?
Each vendor gets an invite with a private upload link. A daily tick looks at which required items are still missing and sends a reminder on a gentle cadence — a nudge at day 3, a follow-up at day 7, and an escalation to your internal contact at day 14. Reminders respect quiet hours and only list what is still outstanding, so a vendor who has done most of it isn’t asked for everything again.
Can the system add a vendor on its own?
No. The whole point is that a human signs off. When every required document is present and not expired, the file moves to a Ready-to-approve state and the owner gets a single message with the complete file and one Approve button. Only on that tap is the vendor written to your system of record, and every action is logged to the vo-audit DynamoDB table for years.
All posts