n8n Supplier Verification: Catch a Failing Supplier Before the PO

A supplier passes your onboarding checks, ships fine for six months, and then an audit reveals their certification expired weeks after you signed. Nobody was watching the gap between onboarding and the next review. The bad batch already shipped on a PO that cleared a supplier who no longer qualified.

n8n supplier verification turns that once-a-year surprise into a daily check. A scheduled workflow reads your supplier ratings, compares each against a threshold you set, alerts your team the instant one drops, and logs every result. The next purchase order goes to a supplier you verified this morning, not at onboarding.

The pages ranking here overshoot. The supplier financial health template leans on ScrapeGraphAI to scrape data and score four weighted risk factors, with a 25-to-30-minute setup and an AI dependency. Powerful, but it's a different problem. Nobody ships the simple, reliable daily rating-threshold check against a sheet a procurement team already keeps. That's the gap.

What supplier verification can automate

Verification is a routine that should never depend on someone remembering to run it:

• Check supplier ratings on a fixed daily schedule, hands-off.
• Compare each supplier against a quality threshold you control.
• Alert your team the moment a supplier drops below the line.
• Catch degradation between onboarding and the next manual review.
• Log every verification result for an audit trail.
• Keep the threshold and recipient list in one Config node.
• Run on two credentials, Google Sheets and an email sender.

That's a control that runs whether or not anyone's looking.

Why simple beats clever here

Here's the stance: for most procurement teams, an AI scraping risk-model is the wrong tool, because the data you actually trust already lives in your own sheet. Scraped financial signals are noisy, the scoring weights are someone else's assumptions, and the setup adds a dependency that breaks quietly when a site changes layout. A rating you maintain is ground truth.

The reliable version reads that ground truth on a schedule and applies one rule. Is this supplier above or below the bar you set? If below, someone hears about it today. There's no model to retrain, no scraper to babysit, no weighting debate. When the alert fires, the team knows exactly why, because the rule is a single number in a Config node.

This isn't anti-AI. It's matching the tool to the problem. Save the scraping pipeline for suppliers whose public financials you genuinely need to watch, and run the cheap daily check on the ratings you already own.

The supplier verification pipeline

Schedule trigger (daily)
        │
   Read supplier ratings from Google Sheets
        │
   Loop each supplier
        │
   IF rating < threshold? ── yes ──► SendGrid alert (name + rating)
        │
   Append result to verification log (Sheets)

Every supplier checked every day, every result recorded.

Step-by-step breakdown

1. Trigger on a daily schedule

A n8n-nodes-base.scheduleTrigger v1.2 fires once a day. Don't reach for the deprecated n8n-nodes-base.cron node; the schedule trigger is the current path and handles intervals cleanly. One run a day is plenty for ratings that change slowly, and it keeps the Google Sheets API quota untouched.

2. Read the supplier ratings

A n8n-nodes-base.googleSheets v4.5 read (resource sheet, operation read) pulls every supplier row. Each row carries at least a name and a current rating. This is the data you already maintain, so verification rides on a source your team already trusts.

3. Check against the threshold

A n8n-nodes-base.if v2 node compares each supplier's rating to the threshold held in a Config Set node, referenced as ={{ $('Config').first().json.minRating }}. Use the v2 IF schema with a numeric condition; the legacy boolean format won't validate. Above the line passes silently; below it routes to the alert branch.

4. Alert the team

Below-threshold suppliers trigger an email through SendGrid. n8n has no dedicated SendGrid node for every operation, so a n8n-nodes-base.httpRequest v4.2 POST to the SendGrid API works cleanly, authenticated with a header credential. The email names the supplier and its current rating, so the recipient acts without opening a dashboard.

5. Log every result

Whether a supplier passes or fails, the run appends a timestamped row to a verification log sheet. That log is the audit trail. Six months from now, when someone asks whether a supplier was being monitored, the answer is a query, not a shrug.

Implementation patterns

Pattern 1 — Threshold-as-config. Keep the quality bar in one n8n-nodes-base.set v3.4 node so procurement adjusts it without touching logic.

Config (minRating) → IF (rating < minRating) → alert

Pattern 2 — Log pass and fail. Append every result, not just the failures. A supplier that's never logged looks the same as one that's passing, and that ambiguity is exactly what bites during an audit.

IF (below threshold) → alert ─┐
                              ├─► append row (status + rating + timestamp)
IF (above threshold) ─────────┘

Pattern 3 — Idempotent daily run. A Schedule trigger that fires while a previous run is still in flight can drop runs. For a once-daily check this rarely bites, but if you tighten the interval, give each run enough headroom or the workflow silently skips a day.

n8n nodes you'll use most

Getting started

1. Build a Suppliers sheet with a name and current rating per row.
2. Add the Schedule trigger and set it to run once a day.
3. Wire the Google Sheets read to pull every supplier.
4. Put the threshold in a Config Set node so it's one number to tune.
5. Add the IF check and the SendGrid alert on the below-threshold branch.
6. Append every result to a verification log sheet.
7. Or import a tested flow and start monitoring today.

Where this fits

Daily verification is one piece of a procurement stack. The same scheduled-check-and-alert shape powers other monitoring jobs, and teams that run several usually standardize on a data pipeline pattern so reads, checks, and logs share one structure. When a verification flags a supplier, the follow-up often touches data validation, since a bad rating and bad data are frequently the same root cause.

A team that verifies suppliers daily stops signing POs to vendors who quietly stopped qualifying. For related automations, see how this connects to broader finance automation, and if your supplier orders also arrive by message, pair this with the Vendor Payment Escalator to keep the payment side honest too.