build.allanninal.dev

Part 1 of 7 · Vendor onboarder series ~5 min read

A vendor onboarder on AWS for a few dollars a month

A new supplier always owes you the same boring pile of paperwork before you can pay them. Their bank details so the payment goes to the right account. A tax form so your books are clean at year-end. An insurance certificate so you’re covered if something goes wrong on a job. A signed agreement. Half the time one piece is missing, one is the wrong year, and the person who chased it left for another job. Setting up a vendor is dull, easy to half-finish, and the gap nobody notices until a payment bounces or an audit finds a vendor with no tax form on file. This post walks through the design of a small onboarder that collects everything a new vendor owes you, checks each document is actually there and not expired, chases what’s missing — and then hands a complete, verified file to a human to approve before the vendor goes anywhere near your accounting system.

Key takeaways

  • Three ways to start a vendor: a quick form, a forwarded email from the supplier, and a Drive sheet row.
  • Every vendor file ends in one of four states on each tick: collecting, ready-to-approve, approved, or rejected.
  • Each required document is checked two ways: is it present, and is it still in date?
  • A daily tick chases only what’s still missing — nudge at day 3, follow-up at day 7, escalate at day 14.
  • Nothing is added automatically. A human approves the finished file. Designed on AWS for about $2.20/month.

The whole system on one page

Before any code, here’s the shape of what we’re designing.

System shape: three inputs, three pieces inside AWS At the top, three external boxes in a row. Far left, "New vendors" — the people and triggers that start a vendor: an owner fills a short form, a salesperson forwards the supplier's first email, or somebody adds a row in a Google Drive sheet. Centre, "Checklist and voice" — a Drive folder with a checklist doc that lists which documents each vendor type owes (bank details, tax form, insurance certificate, signed agreement) and the rules for what counts as in-date, plus a voice doc with the invite and reminder message templates. Far right, "Vendor and owner" — the supplier contact who uploads the documents through a private link, and the internal owner who approves the finished file before the vendor is added. Each connects via an arrow to the AWS account container below. New vendors have an outgoing arrow into AWS. Checklist and voice feed in to ground every check and message. The vendor receives the invite and reminders and uploads documents; the owner receives the complete file with an Approve button. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Invite intake — starts a vendor from each source, creates the vendor folder, and sends the private upload link. In the middle, the Document checker — reads each uploaded file with Textract and Bedrock, decides present-or-missing and in-date-or-expired, and waits for a human to confirm. On the right, the Chase and approve piece — runs daily, reminds the vendor about only what is still missing, and when the file is complete sends it to the owner to approve. Internal arrows flow left to right. A note at the bottom reads: nothing is added automatically — a human approves the finished file, and every action is logged. New vendors form, email, sheet Checklist and voice required docs, templates Vendor + owner uploads and sign-off vendors in grounds invite, then file to approve AWS account Invite intake start vendor, send upload link Document checker reads each file: present? in date? confirmed? Chase + approve reminds, then owner signs off upload status Nothing is added automatically — a human approves the finished file, and every action is logged.
Fig 1. Three inputs outside, three pieces inside AWS. Vendors start from a form, a forwarded email, or a Drive sheet. The Document checker reads each uploaded file and decides present-or-missing and in-date-or-expired. The Chase and approve piece reminds the vendor about only what is left, then sends the complete file to a human to sign off.

What you set up once (the outside)

  • New vendors. A vendor is started in one of three ways, all covered in Part 2: an owner fills a short web form (vendor name, contact email, vendor type), a salesperson forwards the supplier’s first email to a dedicated address, or somebody adds a row to a Google Sheet in a Drive folder. Whichever lane it comes from, the result is the same: a vendor folder is created and the supplier gets a private link where they upload their documents.
  • A checklist folder. Two short Google Docs in a Drive folder. The checklist doc says which documents each vendor type owes — a contractor owes bank details, a tax form, and an insurance certificate; a software supplier might owe only bank details and a tax form. It also holds the rules for what counts as in-date (an insurance certificate must not be past its expiry date; a tax form must be the current year’s version). The voice doc holds the invite message and the reminder messages, so what the vendor reads stays in your tone.
  • Vendor and owner. The supplier contact uploads documents through the private link and receives any reminders. The internal owner gets the complete, verified file at the end with a single Approve button. The file they see lists every required document, whether it’s present, whether it’s in date, and a link to view each one.

What runs on every step (the inside)

  • The invite intake. Takes a new vendor from any of the three lanes, creates a folder in S3 for the documents and a row in DynamoDB for the checklist status, and sends the private upload link by email. The link opens a small upload page (a Lambda Function URL, not a heavy web app) where the vendor drops their files one at a time.
  • The document checker. When a vendor uploads a file, it reads it once. Textract (a managed service that reads text out of PDFs and images) pulls the words off the page, and Bedrock Haiku 4.5 reads those words and proposes what kind of document it is and the few fields that matter — the tax-ID on a tax form, the expiry date on an insurance certificate. Plain Python then decides two things: is this required document now present, and is it still in date? A person confirms the read before the item counts as done, because a misread expiry date is worse than a missing one.
  • The chase and approve piece. Runs once a day. For each vendor still collecting, it looks at what’s outstanding and sends a reminder that lists only the missing items. The cadence is gentle — a nudge at day 3, a follow-up at day 7, an escalation to your internal contact at day 14. When every required item is present, in date, and confirmed, the vendor file flips to ready-to-approve and the owner gets one message with the whole file and an Approve button. Nothing is written to your system of record until the owner taps it.

In plain words

You agree to start using Bright Spark Electrical for site work. You open the form, type their name and the foreman’s email, pick “contractor,” and submit. Bright Spark gets an email: “To get set up as a supplier, please upload four things — your bank details, your W-9, your certificate of insurance, and the signed agreement.” They upload the bank details and the W-9 that afternoon. The checker reads both, you confirm them, and two items go green. The insurance certificate and the signed agreement are still missing, so three days later Bright Spark gets a friendly reminder that lists only those two. The certificate arrives; the checker reads its expiry date and notices it lapsed last month, so that item stays red with a note. A day-7 follow-up asks for a current certificate and the agreement. Both arrive, both check out, and the file flips to ready-to-approve. You get one message: the whole Bright Spark file, every item green, with an Approve button. You tap it, and only then is Bright Spark written into your accounting system as a payable vendor.

The cost of running this is about $2.20 a month at SMB volume. The cost of not running it is the payment that goes to a stale bank account, the year-end scramble for a tax form nobody collected, and the uninsured contractor who was already on a roof before anyone checked.

Design rules that shaped every decision

  • Every vendor owes a known list. The checklist doc, not code, says what each vendor type must provide.
  • Two checks per document, always: is it present, and is it still in date? A stale certificate fails the second one.
  • A human confirms every read. A misread tax-ID or expiry date is caught before it counts as done.
  • Reminders list only what’s left. A vendor who has done most of it is never asked for everything again.
  • Nothing is added automatically. The owner approves the finished file; only then is the vendor written to the system of record.
  • Every action is logged. Audit a vendor next year and you can see who approved it, when, and on what evidence.

Why this shape

Most small teams onboard vendors in one of three ways: a person who emails the supplier back and forth until the paperwork is in, a shared folder that’s missing half its files, or not really at all — the vendor gets paid and the documents get collected “later,” which means never. The person works until they’re busy, and the weeks they’re busiest are exactly when new vendors pile up. The folder is storage, not a system: it holds what arrived but says nothing about what’s missing or out of date. And “not at all” is how a business ends up paying a vendor whose insurance lapsed and whose tax form was never on file.

The setup above keeps the simple parts simple — a checklist in a doc, files in a folder — but adds a small system that watches each vendor file and acts only when something is missing or expired. Invites go out the moment a vendor is started. Reminders are polite and list only what’s left. Each document is checked for being present and for being in date. And the finished file always lands in front of a human before anything is added. The onboarder is invisible once a vendor is set up; it only shows up while a supplier still owes you paperwork.

The next four posts walk through each piece in turn: how a vendor gets invited, how a vendor document gets checked, how a vendor gets chased for missing items, and how a vendor file gets approved. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts