Late payments are a cash-flow problem that's also a social one: you need to remind clients, but a duplicate or a reminder for an invoice they already paid is embarrassing. Here's a structure for a reminder system in n8n using Google Sheets, Telegram and Gmail. No AI is needed.

1. The Sheet is the source of truth

One row per invoice: invoice_no, client_id, client_name, email, lang, amount, currency, issue_date, due_date, status (open/paid/cancelled), plus a Clients tab with a paused flag per client. Optionally, add a Webhook node (Header Auth) so other tools can upsert invoices by invoice_no and mark them paid. Validate input and return a 422 with the reasons when a row is bad.

2. A daily planner with stages

Define stages relative to the due date, e.g. [-3, 0, 7, 14] days. Each morning, for each open invoice:

• skip if paid or cancelled, if the client is paused, if a reminder is still waiting for approval, or if no stage has been reached yet;
• enforce a minimum gap since the last reminder;
• pick the latest stage reached.

3. Idempotency: one key per invoice + stage

Hash invoice_no + due_date + stage into a short key (including the due date means a moved due date starts a fresh schedule) and store it in a "Reminders" tab. If the key exists, don't plan it again. This makes re-runs safe: run the planner five times, and you still get one reminder per stage.

const crypto = require('crypto');
const key = crypto.createHash('sha256')
  .update(`${$json.invoice_no}|${$json.due_date}|${$json.stage}`).digest('hex').slice(0, 16);

(This snippet needs the crypto module allowed in your n8n Code node settings. The packaged template uses a small built-in hash instead, so it needs no module.)

4. Texts per language, with a firmer last stage

Keep templates in a Config node: Hebrew and English, amount formatted with ₪/$/€, due date, days overdue, your payment details (for example bank-transfer info) and the invoice number. The final stage can be firmer but stays polite.

5. Approve before anything is created

Send a Telegram card with the full text: Approve / Skip / Pause client. On Approve, re-check the Sheet: if the invoice got paid or the client was paused since the card went out, do nothing. Otherwise create a Gmail draft. Auto-sending should be an explicit opt-in switch, not the default.

6. Reports

• Weekly aging report per currency: not yet due, 0–30, 31–60, 60+.
• Monthly summary: issued, paid, average days late, reminders by outcome. Draft it to your accountant.

Limits to know: if you forget to mark an invoice paid, the system will still suggest a reminder (you can Skip it). There's no bank reconciliation here.

My packaged version is Payment Reminders & Receivables Chaser for n8n: 6 workflows, 10 fictional sample invoices (ILS/USD/EUR), webhook examples and a setup guide. It was tested on self-hosted n8n 2.43.7 and needs n8n reachable over public HTTPS, Sheets + Gmail OAuth and a Telegram bot. It was tested against mocked services, not real accounts. Details: https://payhip.com/b/jdz7B

Most "AI email assistant" demos end with the model replying to customers by itself. For a small business that's the scary part: one confident, wrong answer to a lead costs more than the time saved. This is how I structure Gmail triage in n8n so the AI does the sorting and the first draft, and a person stays in charge of anything that leaves the inbox.

1. Intake: poll, validate, de-duplicate

• Gmail Trigger polling every minute, plus a manual "sweep" path for the existing backlog.
• Drop your own addresses, sent items and empty emails before spending an API call on them, and flag no-reply / bulk senders so they never get a draft.
• De-duplicate on the Gmail message id. Store every processed id (a Google Sheets "Triage log" works) and skip ids you've seen. Without this, a re-run of the sweep triages everything twice.

2. One AI call, strict JSON

Make one OpenAI call per email and ask for a fixed JSON shape, for example:

{"category":"lead|support|invoice|spam|other","priority":"urgent|high|normal|low",
 "language":"he|en|other","summary":"...","next_step":"...","draft_status":"drafted|needs_human|not_needed",
 "draft_reply":"...","used_sections":["pricing","hours"],"confidence":0.0}

Feed it only the most relevant sections of your own knowledge doc (prices, hours, policies), not the whole thing. Read the email as plain text and cap its length.

3. Guards after the model

This is the step most tutorials skip. In a Code node, reject the output when:

• the JSON doesn't parse, or the category isn't one of yours;
• the draft is empty;
• the draft cites no section of the knowledge doc that was actually sent to the model.

Any of these means no draft at all: the email is flagged "needs a person". Low confidence is shown as a warning instead of being hidden. Be honest about what this does not catch: a draft that cites a section but is subtly wrong still passes. That's why the next step exists.

4. Human approval in Telegram

Send a card with the summary and draft and three buttons: Approve / Edit / Reject. Edit = reply to the bot message with new text. Approve creates a Gmail draft in the same thread, not a sent email. Check that the tap came from an allowed approver id and that the card isn't stale.

5. Labels and a tiny CRM

Apply Gmail labels (AI/Lead, AI/Support, AI/Urgent…), creating them if missing. For lead, support and invoice emails, upsert one row per sender in a Sheets "Contacts" tab: category, status, next step, last contact.

6. Production basics

• Retries on Gmail / Sheets / OpenAI / Telegram nodes.
• A separate error workflow that writes a DeadLetter row and alerts you; if OpenAI is down, the email isn't logged, so retrying the failed execution or running the manual sweep (last 3 days) picks it up again. The Gmail trigger won't deliver it a second time.
• A daily summary: counts by category, waiting approvals, drafts never sent.

Expect misclassifications in the first weeks; check the labels and tune your categories and knowledge doc.

If you'd rather not build it from scratch, I packaged my version as AI Inbox Triage for n8n (5 workflows, sample knowledge doc and test emails, setup guide). It was tested on self-hosted n8n 2.43.7 and needs n8n reachable over public HTTPS, Gmail + Sheets OAuth, your own OpenAI key (you pay OpenAI per email) and a Telegram bot. It was tested against mocked services, not real accounts, and the AI quality depends on your model and knowledge doc. Details: https://payhip.com/b/jgKmD

Supplier invoices arrive as PDFs in your inbox, photos of receipts, and the occasional newsletter someone forwarded by mistake. Typing them into a spreadsheet is boring, and handing the whole job to an AI is risky: models misread numbers, and a wrong total that slips through is worse than no automation at all.

This article shows how I structured an invoice pipeline in n8n that uses AI for the tedious part (reading the document) and plain code plus a human tap for the part that matters (deciding what's correct and what gets paid). The template's checks are set up for Israel (18% VAT, ILS, the 9-digit Israeli business-number checksum). The pattern carries over to other countries, but you'd change the VAT rate and currency in Config and replace the ID checksum in code.

The problem

A useful invoice pipeline needs to:

1. Accept documents from more than one place (email and upload).
2. Read both text PDFs and images.
3. Turn them into structured data without the model inventing fields.
4. Check the numbers instead of trusting them.
5. Never process the same document twice.
6. Never mark anything paid without a person agreeing.

The architecture

Four workflows:

• 0 Error Handler: writes a DeadLetter row to Google Sheets and sends a Telegram alert when anything fails.
• 1 Intake: Gmail trigger and upload webhook, extraction, validation and routing.
• 2 Approvals: handles the Approve and Reject buttons in Telegram.
• 3 Monthly Summary: totals per vendor and VAT, sent to Telegram and drafted in Gmail for your accountant.

Each workflow has its own Config node (Sheet ID, tab names, Telegram chat ID); the VAT rate, tolerances and confidence threshold live in the Intake workflow's Config.

Diagram: the four workflows. Invoices come in from two places: a Gmail inbox checked every minute, or an authenticated upload webhook. Both feed workflow 1 (Intake). Intake sends the document to OpenAI to extract the fields, writes clean documents to the Invoices tab and problem ones to the Review tab in Google Sheets, and messages you in Telegram. Tapping Approve or Reject in Telegram runs workflow 2 (Approvals), which updates the row's status. On the 1st of each month at 08:00 (instance timezone), workflow 3 (Monthly Summary) reads both tabs and posts a summary to Telegram plus a Gmail draft. If anything fails, workflow 0 (Error Handler) writes a row to the DeadLetter tab and sends a Telegram alert.

• 0 Error Handler: Error Trigger → Config → Fetch Failed Execution (n8n API, optional) → Build Dead-Letter Row → Append to DeadLetter + Telegram Alert
• 1 Intake: Gmail Trigger / Intake Webhook → … → AI Extract (LLM) → Validate & Route → Invoices or Review (see the next diagram)
• 2 Approvals: Telegram Trigger → Config → Parse Callback → Valid & Authorised? → Find Invoice Row → Check State → Pending? → Row Update → Update Status in Sheet → Answer: Done → Edit Message (remove buttons); with the side answers Answer: No Change and Answer: Not Allowed
• 3 Monthly Summary: Monthly Schedule (1st, 08:00) / Run now → Config → Read Invoices → Read Review → Build Summary → Telegram Summary + Send Email or Draft? → Gmail: Send Summary or Gmail: Draft Summary (draft is the default)

Step by step: the node logic

Intake

• Gmail Trigger polls the inbox every minute for emails with PDF, PNG or JPG attachments. Intake Webhook accepts authenticated multipart uploads, several files at once. Both feed one Config node.
• Split Attachments turns each file into its own item.
• Read Invoices, Read Review and Skip Already Processed implement idempotency with a content hash. If Gmail re-polls or a retry runs, nothing gets duplicated.
• From Webhook? / Respond to Sender answers upload callers quickly.
• PDF or Image? splits the path. PDFs go through Extract PDF Text. Images (PNG, JPG, WebP) are sent to the model's vision input. Merge PDF + Image joins them again.
• Prepare LLM Request and AI Extract (LLM) ask the model to fill a strict JSON schema: vendor, business number, invoice number, date, net, VAT, total, currency and a confidence score. A strict schema means the model can't add fields you didn't ask for. The default model is gpt-4o-mini (set in Config). The request goes to the OpenAI API; using another OpenAI-compatible endpoint means editing the URL and credential in the AI Extract node.
• Validate & Route is where the real work happens, in plain code:
  • VAT equals net × 18%, within a tolerance you set
  • net + VAT = total
  • the 9-digit Israeli business number passes its checksum
  • required fields are present
  • vendor + invoice number isn't a duplicate
  • the AI's confidence is above your minimum
  • the document is actually an invoice
• Approve or Review? sends clean documents to the Invoices sheet with status pending_approval and a Telegram message with Approve and Reject buttons. Problem documents go to the Review sheet with the reason, plus a Telegram alert.

Approvals

• Telegram Trigger receives the button tap. Parse Callback and Valid & Authorised? reject malformed data and taps from people who aren't approvers (a list of Telegram user IDs, or anyone in your configured chat if you leave the list empty).
• Find Invoice Row and Check State make sure the invoice is still pending, so a stale re-tap does nothing.
• Update Status in Sheet sets approved_paid or rejected with who tapped and when, and Edit Message removes the buttons. This only records the decision in the sheet. The template doesn't pay anything or connect to a bank or accounting software. Nothing is marked paid until you approve it in Telegram.

Monthly Summary

A monthly schedule (the 1st of each month at 08:00, instance timezone), or a manual run for testing, reads both sheets, builds totals per vendor, VAT totals and status counts, posts them to Telegram and creates a Gmail draft for your accountant. Sending directly is a config switch you have to turn on yourself.

Diagram: the Intake node chain. Left to right: two triggers merge into one Config node. Attachments are split and fingerprinted, and files already in the sheet are dropped. Upload callers get an immediate reply. Then the path splits: PDFs have their text extracted, while images go straight on. The two paths merge, the AI request is built and sent, and the result is checked in code. The last switch sends clean documents to Invoices (pending_approval) with Approve/Reject buttons in Telegram, and everything else to Review with a Telegram alert.

1. Gmail Trigger (polls every minute) / Intake Webhook (POST, header auth)
2. Config
3. Split Attachments
4. Read Invoices → Read Review → Skip Already Processed
5. From Webhook? → yes: Respond to Sender → Has New Files?; no: Has New Files?
6. PDF or Image? → pdf: Extract PDF Text → Merge PDF + Image; image: Merge PDF + Image
7. Prepare LLM Request → Needs LLM? → yes: AI Extract (LLM, OpenAI) → Validate & Route; no: Validate & Route
8. Approve or Review? → approve: Append to Invoices → Telegram: Ask Approval; review: Append to Review → Telegram: Review Alert

Pitfalls

• Don't trust the model's arithmetic. Have it extract the numbers, then check them in code. That's the whole design.
• Scanned PDFs without a text layer have no text to extract. In this design they end up in Review. No OCR engine is included, so add one if most of your documents are scans.
• Idempotency by hash, not filename. Suppliers resend "invoice.pdf" all the time.
• Lock down the approval buttons. Check the chat ID and the current state, or anyone who can forward a message can mark things paid.
• Draft, don't send. Let a human hit send on the accountant email until you trust it.
• Retries are fixed-wait. n8n's built-in retry here is 3 tries, 3 seconds apart, not exponential backoff.

Testing it

I tested on self-hosted n8n 2.43.7 against local mocks of Gmail, Sheets, Telegram and OpenAI, with a set of fictional sample documents in Hebrew and English. Cases worth reproducing:

• one clean invoice per supplier type
• a wrong-VAT invoice, a bad business number, and a missing invoice number
• an exact duplicate
• a low-confidence handwritten receipt
• a document that isn't an invoice
• a non-JSON reply from the AI
• wrong file type, missing file and wrong token on the upload
• approve, reject, stale, unauthorised and forged taps
• a forced AI outage: retries, then a DeadLetter row and an alert, with nothing half-written

One honest caveat: the mock returned correct extractions, so this proves the plumbing, not the AI's accuracy on your documents. Run a batch of your real invoices before relying on it, which the approval step is there to catch anyway.

Setup

You'll need: n8n (tested on self-hosted 2.43.7), a Gmail account, Google Sheets, an OpenAI API key (you pay OpenAI's usage costs), and a Telegram bot.

If you'd like the finished version (four workflows, sample documents with expected results and a setup guide), it's here: https://payhip.com/b/Xk4M0

If you run a clinic, a studio or any business that lives on appointments, a lot of your WhatsApp traffic is the same handful of messages: "Do you have something tomorrow?", "Can I move my Thursday slot?", "Where do I park?". Meta's webhook has quirks, customers write dates a dozen different ways, two people can grab the same slot, and sooner or later someone needs a real human.

Here's how I structured one in n8n to handle those cases.

The problem, in concrete terms

A booking bot has to get five things right:

1. The webhook. Meta verifies your endpoint with a GET request, expects a fast 200 on every POST, signs payloads with X-Hub-Signature-256, sends status callbacks (sent, delivered, read) you don't care about, and can deliver the same message twice.
2. Understanding the request. "מחר בארבע וחצי", "next Thursday", "Oct 23rd at 4pm".
3. Availability. The slot must actually be free in the calendar, inside opening hours, with enough notice.
4. Race conditions. A slot that was free when you offered it may be gone by the time the customer says "yes".
5. Handoff. When the bot doesn't understand, it should say so and get a person involved, not guess.

The architecture

Six workflows, each with its own Config node:

• 0 Error Handler: catches failures from the others, writes a DeadLetter row to Google Sheets and sends a Telegram alert.
• 1 Inbound: the Meta webhook. Verification, signature check, filtering and de-duplication.
• 2 Conversation Engine: understands the message, checks Google Calendar, books, moves or cancels, and replies.
• 3 Staff Telegram: lets staff reply to customers from Telegram and hand the chat back to the bot.
• 4 Reminders: runs every 30 minutes and sends a reminder template before appointments.
• 5 Daily Summary: a Telegram summary for the owner every evening.

Diagram: the six workflows. A customer's WhatsApp message reaches Meta's WhatsApp Cloud API, which calls workflow 1 (Inbound) on /webhook/whatsapp. Inbound acknowledges Meta, verifies the signature, drops delivery receipts and duplicates, then calls workflow 2 (Conversation Engine) once per message. The engine reads and saves conversation state and appointments in Google Sheets, checks and writes Google Calendar, replies through the Cloud API, and alerts staff in Telegram on handoff. Staff actions in Telegram (Resume, or a reply) run workflow 3, which sends the reply on WhatsApp. Two scheduled workflows run alongside: workflow 4 checks every 30 minutes for appointments in the next 24 hours and sends an approved reminder template, and workflow 5 posts the owner's daily summary to Telegram at 20:00 (instance timezone). Workflow 0 logs any failure to a DeadLetter tab and alerts Telegram.

• 0 Error Handler: Error Trigger → Config → Fetch Failed Execution (optional) → Build Dead-Letter Row → Append to DeadLetter + Telegram Alert
• 1 Inbound: WhatsApp Verify (GET) / WhatsApp Events (POST) → Config → Verification Request? → (GET) Verify Token OK? → Respond: Challenge or Respond: Forbidden; (POST) Respond: 200 OK → Verify Signature & Parse → Customer Messages Only → Read Processed → Skip Duplicates → Mark Processed → Restore Messages → Run Conversation Engine
• 2 Conversation Engine: see the next diagram
• 3 Staff Telegram: Telegram Trigger → Config → Parse Admin Update → Resume, Reply or Refuse? → resume: Read Conversation → Resume Row → Save Conversation → Answer: Resumed → Edit Alert; reply: Read Conversation → 24h Window Check → Send to Customer → Confirm to Staff; refuse: Answer: Not Allowed
• 4 Reminders: Every 30 Minutes / Run now → Config → Read Appointments → Read Conversations → Due Reminders → Send Reminder Template → Check Results → Sent or Failed? → sent: Row Update → Mark Reminder Sent; failed: Telegram: Reminder Failed
• 5 Daily Summary: Every Day 20:00 / Run now → Config → Read Appointments → Read Conversations → Build Daily Summary → Telegram: Daily Summary

Step by step: the node logic

Inbound

Two webhook nodes share the path: WhatsApp Verify (GET) and WhatsApp Events (POST). For GET, an IF node checks the verify token and responds with the challenge or a 403.

For POST, the very first thing is Respond: 200 OK. Meta retries slow webhooks, so you acknowledge first and work after. Then:

• Verify Signature & Parse (a Code node) computes the HMAC-SHA256 of the raw body with your App Secret and compares it to X-Hub-Signature-256. Forged calls are dropped.
• Customer Messages Only discards status callbacks.
• Read Processed and Skip Duplicates look up the WhatsApp message id in a Processed sheet, and Mark Processed records new ones. That is your idempotency layer.
• Run Conversation Engine hands each new message to workflow 2.

Conversation Engine

• Read Conversation and Read Appointments load the state for that phone number from Google Sheets: what was offered and what is waiting for confirmation.
• Understand & Decide is a rule-based Code node. It parses Hebrew and English dates and times and matches your service names and keywords. It understands Hebrew and English only; voice notes, images and documents aren't read. I chose rules over an LLM here on purpose: it is predictable, costs nothing per message, and when it doesn't understand, it knows it doesn't.
• Next Step routes to booking, rescheduling, cancelling, a FAQ answer or a handoff.
• Calendar: Free/Busy and Pick Slot find the requested slot or the nearest free alternatives, same day first, respecting opening hours, minimum notice and closed days.
• When the customer confirms, free/busy is checked again right before Calendar: Create Event. This second check is what prevents most double-bookings.
• Rescheduling moves the same event (Calendar: Move Event). Cancelling deletes it after a confirmation. Every change is mirrored to an Appointments sheet. Bookings go into one Google Calendar (calendar_id); there's no per-staff calendar routing.
• FAQ answers come only from your own clinic info, with a whole-word coverage guard. If nothing matches, the bot says it doesn't have a reliable answer and offers a person. Optional AI rephrasing (AI Answer (LLM)) only rewords the matched text and falls back to the exact text.
• Send WhatsApp Reply and Save Conversation close the loop.

Staff Telegram and handoff

Handoff triggers on words like "נציג" or "human", urgent keywords, or three misunderstood messages in a row. Staff get a Telegram alert, the bot goes quiet for that chat, and new customer messages are forwarded. Staff reply in Telegram and it goes out on WhatsApp. A Resume button gives the chat back to the bot.

A 24h Window Check node handles WhatsApp's 24-hour rule. Inside the window, the staff text goes out as is. Outside it, an approved template is sent instead and staff are told why.

Diagram: Conversation Engine branches. The engine loads the customer's state, then a rule-based Code node decides what the message is. A six-way switch routes it: booking goes to a free/busy lookup, then Pick Slot, which offers a time or alternatives. Once the customer says "yes", Pick Slot checks free/busy again and only then branches to Create Event (new booking) or Move Event (reschedule). Cancel deletes the event. An FAQ answer goes through the optional AI rephrasing step. Handoff alerts staff in Telegram, and a paused chat just forwards the message to Telegram. Every branch except "paused" ends in one Prepare Reply → Send WhatsApp Reply step, and the conversation state is saved last.

1. From Inbound → Config → Read Conversation → Read Appointments → Understand & Decide (rules, Hebrew + English)
2. Next Step (switch):
   • calendar → Calendar: Free/Busy → Pick Slot (re-checks free/busy before writing) → Create, Move or Reply?
     • create → Calendar: Create Event → Booked → Save Appointment → Prepare Reply
     • move → Calendar: Move Event → Moved → Update Appointment (moved) → Prepare Reply
     • reply → Prepare Reply
   • cancel → Calendar: Delete Event → Cancelled → Update Appointment (cancelled) → Prepare Reply
   • handoff → Telegram: Handoff Alert → Prepare Reply
   • paused → Telegram: Forward Message → Conversation Row
   • ai (answer_mode = llm) → AI Answer (LLM) → Use AI Answer → Prepare Reply
   • reply → Prepare Reply
3. Prepare Reply → Send WhatsApp Reply → Conversation Row → Save Conversation

Pitfalls I hit, so you don't have to

• Don't do work before the 200. If your webhook runs the whole flow before responding, Meta will retry and you'll get duplicates.
• De-duplicate on message id, not content. People do send "yes" twice on purpose.
• Ignore status callbacks early. Otherwise every outgoing message triggers your engine.
• Check availability twice. Once to offer, once to book. There's still a tiny race window if two bookings land in the same second, but it's very small.
• Templates need Meta approval. Reminders and out-of-window staff replies depend on approved utility templates, and Meta may charge for template messages; check current WhatsApp pricing. Submit them early.
• Voice notes and images aren't understood in this design. The bot asks for text.
• Set the timezone. Set the timezone in your clinic config (and in the Reminders/Summary Config). Also set n8n's GENERIC_TIMEZONE so the 20:00 summary runs at your local time.

Testing it

I tested on self-hosted n8n 2.43.7 with local mocks of the WhatsApp Cloud API, Google Calendar, Sheets, Telegram and OpenAI, on self-hosted n8n 2.43.7. The cases worth copying into your own test plan:

• GET verify with the right and the wrong token
• a bad or missing signature
• the same message delivered twice
• a busy slot leading to alternatives and then a booking
• a slot taken between the offer and the "yes"
• reschedule and cancel
• handoff, then a staff reply, then Resume
• a staff reply outside the 24-hour window
• a forced Google Calendar outage: retries, then one DeadLetter row and an alert, and nothing half-booked

What I have not tested: a real Meta app and template approval, real Google and Telegram accounts, and real customer phrasing beyond my test sentences. Test with your own number before you put it in front of customers.

Setup

You'll need: n8n (tested on self-hosted 2.43.7) reachable over public HTTPS, a Meta app with the WhatsApp Cloud API (not the regular WhatsApp Business app), Meta-approved utility templates, Google Calendar, Google Sheets and a Telegram bot. An OpenAI key is optional, only for AI rephrasing of FAQ answers. Meta's fees may apply.

If you'd rather not build it from scratch, I sell the finished version (six workflows, Hebrew and English sample configs and a setup guide) here: https://payhip.com/b/BPTjN