Hi Andrew, built this to see if it’d actually work. Fake data, not your clients:
https://www.loom.com/share/9e6add04757645a3bb0d5ef222bb4765
Sheet says who’s due, it grabs that client’s PDF from Drive, sends it, marks the row done so nobody gets billed twice.
One thing in the brief needs settling before anyone quotes you, because it changes the build: Make runs in the cloud, so it cannot see your desktop, and it has no iCloud Drive connector. Whatever the final workflow looks like, the PDFs have to live somewhere Make can actually reach — Google Drive being the obvious one since you’re already in Sheets.
That’s not a blocker, it’s a first step: point your invoice folder at Drive (or sync the desktop folder into it) and the rest of what you described is straightforward.
The part that actually deserves care is matching. Emailing invoice 4471 to the wrong client is worse than the automation not existing, so:
Mid-month and end-of-month cycles are just a date rule on top of that, once the matching is trustworthy.
I do this kind of work as fixed-price per deliverable — you’d know the cost before I start. If you post a few of your invoice filenames, I’ll tell you plainly whether the matching is clean or needs a convention first.
Async, Paris CET, remote-only delivery — written briefs over meetings.
Hi Andrew,
Most replies here flag the same blocker — Make can’t reach PDFs sitting on your desktop or iCloud. That’s correct, but it’s solvable, and I’d rather solve it than ask you to change how you work.
Two options, pick whichever fits:
A. Keep your current workflow. A small watcher runs on your computer and mirrors your invoice folder into a Google Drive folder automatically. You keep saving invoices exactly where you do now. Make sees them in Drive and takes over from there. Setup is one-time, then it’s invisible.
B. Skip Make for this one. A single script reads your Google Sheet, matches each client to their PDF in the local folder, sends the email with the invoice number in the subject, and writes the send status back to the sheet. Manual re-send is one line in the sheet. No cloud dependency, no monthly operation cost.
Both handle what you actually asked for: mid/end-of-month selection, status write-back, and one-off re-sends.
What I need to be exact rather than vague: how are your PDF files named? If the filename contains the invoice number or client name, matching is trivial. If not, I’ll read the number from inside the PDF — also fine, just worth knowing upfront.
Price and timeline: $180 fixed, 2 days. That covers the working setup, a short written guide, and fixes if something misbehaves in the first month.
I work in writing only — no calls needed. Happy to send a working demo on 3 test invoices first so you can see it run before committing to anything.
This is feasible if the PDFs live in Google Drive and follow a consistent naming rule. I would not base the production version on files sitting only on a desktop or in iCloud because Make cannot reliably reach those files when the computer is offline.
The build I would recommend is: Google Sheets controls the billing cycle and recipient data, Google Drive holds the PDFs, Make matches the invoice, Gmail sends it, and the Sheet records sent time, file name, recipient, and any error. A manual resend field can trigger one invoice without rerunning the whole batch.
For about 80 recurring clients, including testing, documentation, and a walkthrough, I would expect a fixed scope around $1,500-$2,500 if the file names and client data are already consistent.
Are the PDF file names tied to a client ID, company name, or invoice number today?
Hi Andrew,
Is this project still open? If so, I can take it on as a fixed-scope Make build.
I would structure it around Google Drive rather than direct desktop or iCloud access, since Make needs a reliable cloud source for the PDF files.
The workflow would:
Read the client details and billing cycle from Google Sheets.
Match each client to the correct PDF in Google Drive using a stable client or invoice identifier.
Validate the match before sending, so an incorrect invoice cannot be attached silently.
Send the invoice through Gmail using your required email template and subject format.
Write the sent status, timestamp and invoice reference back to the Sheet.
Prevent duplicate sends during reruns.
Include a controlled manual-resend option for an individual client.
Log missing files and failed sends for review.
My relevant experience includes building and maintaining Make workflows that match Shopify orders and transaction data to Airtable records, calculate cumulative payments and outstanding balances, update operational systems, and handle testing and handover for non-technical teams.
My fixed price would be USD 400, with delivery within two business days once access and the required samples are available. This includes testing, a recorded walkthrough, concise documentation and seven days of minor post-delivery support.
Before confirming the scope, I would need:
An anonymised example of the Google Sheet columns.
Three sample PDF filenames showing the current naming convention.
Confirmation of how mid-month and month-end clients are identified.
Your preference for the manual-resend trigger.
If the project is still available, you can send those privately and I’ll confirm the final build plan before any access is shared.
Hi Andrew,
Is this project still open? If so, I can take it on as a fixed-scope Make build.
I would structure it around Google Drive rather than direct desktop or iCloud access, since Make needs a reliable cloud source for the PDF files.
Hi Andrew, this looks like a good fit for a staged Make build.
Before quoting the full workflow, I would verify the file source. PDFs need to be in Google Drive or another cloud location Make can access. I would also confirm that each Sheet row and invoice filename share a stable client or invoice ID.
I can start with a fixed $125 feasibility and field mapping review covering the billing filter, PDF lookup, recipient validation, duplicate protection, sent status, and manual resend path. No credentials or live client data are needed.
If that approach works, share one redacted invoice filename and the relevant Sheet columns.
Hi, I can automate your PDF invoice emailing today.I specialize in Make.com workflows, Google Sheets/Drive integrations, and reliable document automation. I can build a clean scenario that:
• Generates the PDF
• Stores it in Drive
• Emails it automatically
• Includes logging + error handlingI can start immediately and deliver same‑day.If you want, I can also optimize any existing steps so the workflow runs faster and more reliably
Hi Andrew,
If this project is still open, I’d be interested in building it.
I work with Make/n8n, Gmail, Google Sheets, Google Drive, APIs, webhooks, and database-backed automations.
For your workflow, I’d use Google Drive for the invoice PDFs and build the automation around reliable client/invoice matching, duplicate-send protection, delivery tracking, manual resend, and error handling.
Fixed price: $300
Delivery: 2–3 business days
Included: implementation, testing, documentation, and walkthrough.
I can also share examples of my automation work and GitHub.
If the project is still available, feel free to reply here and we can discuss the details.
Hi Andrew,
I can build this workflow in Make.
I agree with the point raised above that the invoice files must be stored in, or reliably synced to, a cloud location such as Google Drive before Make can process them.
For the stated scope, I would build:
• A billing schedule in Google Sheets containing each client’s stable ID, email address and billing cycle
• Matching between that client ID and the correct invoice PDF in Google Drive
• Scheduled mid-month and end-of-month processing
• Validation to stop an email if no invoice—or more than one matching invoice—is found
• Email delivery with the correct attachment and subject line
• A delivery log recording the date, status and any error
• A simple manual resend option
• Documentation and a recorded walkthrough
Fixed price: USD 250
Delivery: 2–3 business days after receiving access and sample files
This assumes the PDFs already exist and contain, or can be renamed to include, a stable client identifier. Invoice generation itself would be outside this scope.
My relevant work includes Make automations connecting Airtable, Shopify and Google Workspace, with validation, status tracking and operational handover:
https://nhlanhla-systems.lebonemak.chatgpt.site
If the requirement is still open, I can review one anonymised invoice filename and the relevant Sheet columns before confirming the build.
Nhlanhla
Hi Andrew,
I can deliver this as a fixed-scope Make build for USD 195 within 3 business days after receiving one anonymized invoice filename and your Sheet column names.
The workflow would:
If invoices must continue to be saved on the desktop, I would first add a reliable sync into Google Drive; Make should not depend on direct desktop or iCloud access.
The fixed price includes implementation, testing with redacted/sample data, documentation, and a recorded walkthrough. Invoice generation is outside this scope.
If the project is still open, please share the filename pattern and whether the mid-month/end-of-month cycle is already a Sheet column. I can confirm the exact field mapping before requesting access.
Rook Operations
The Google Drive + PDF matching approach is a good example of why reliable file identification matters in automated workflows. The same pattern can be useful when managing other types of downloadable resources too, including game-related PDFs, guides, and utility files—especially when multiple versions or files need to be kept organized. I came across this resource while looking at that side of file-based gaming resources, and the same idea of using stable file references rather than filenames alone applies.
Hi Andrew — if this is still open, I can take a very small first milestone rather than asking you to commit to the full 80-client rollout.
For £125 fixed, I’ll validate 5 redacted clients end-to-end: Sheet billing-cycle rule → exact Drive PDF match → Gmail send → sent/error write-back → controlled resend, with duplicate/missing-file protection and a short handover.
I can return that pilot within 24 hours of receiving the redacted Sheet headers + sample filenames. If the pilot works cleanly, we can scope the full rollout separately.
Would that be useful?
Hi Andrew,
I read your requirements. To make sure I understood the scope: you need
the automation to read the client list from Google Sheets, identify which
clients are due in the current billing cycle, locate the correct PDF
invoice, email it, update the status back in the Sheet, and allow a resend
without creating duplicates.
Two questions before I quote:
On the duplicate-resend point, which is the part most people get wrong:
an automation that just appends a “sent” record will create duplicates
whenever a run is retried after a timeout. The correct approach is to
write the status keyed on the invoice ID, so a retry updates the existing
row instead of adding a second one. I ran into exactly this in my own
pipeline and documented the fix here:
I work in n8n rather than Make, and both are node-based automation tools
with the same webhook-scenario-storage model. I’d rather tell you that
up front than discover it mid-project.
I’m available to start now and I work asynchronously in writing.
David Bertorello
Hi Andrew,
You asked for an estimate and I left mine open pending my two questions, which was my mistake. Here it is, priced both ways so you do not have to answer first:
Both cover the same scope: read the client list from Sheets, filter the mid-month / end-of-month cycle, match the correct PDF, send it with the invoice # and name in the subject, write the status back, and support a manual resend.
Delivery 3-4 business days, paid on acceptance after it runs against your real 80-client list - not before.
One thing I would rather say up front: my documented automation work is in n8n, not Make. The transferable part is real (Sheets and Drive APIs, retry-safe writes, error handling) and this build is straightforward in Make, but I would rather you know that now than find out later.
The resend-without-duplicates part is the one I can actually show rather than claim - the write is keyed on the invoice ID, so a retry updates the existing row instead of appending a second one. Full write-up and workflow JSON here: GitHub - davidbertorello82-boop/enterprise-content-ingestion-pipeline · GitHub
David
Two things in the spec decide whether this is a clean build or a monthly
firefight:
The PDFs cannot live on the desktop or in iCloud. Make has no reach into a local
disk, so step one is that invoices land in Google Drive — synced folder, or moved
there as part of your existing manual process. Everything downstream is
straightforward; this one assumption is where this project would otherwise stall.
Matching is the real design decision. Locating “the corresponding PDF” for 80
clients only works if the filename carries the join key — something like
CLIENTID_YYYY-MM_INVOICENO.pdf. With a convention, matching is exact and
unmatched invoices route to a review list instead of being guessed at. Without
one, someone hunts through Drive every cycle and the automation saves nothing.
Related: the “mark as sent” write-back needs to be an idempotency key, not a
cosmetic flag — client plus billing period, checked before sending. A re-run that
emails 80 clients their invoice a second time is worse than a run that fails.
Scope I’d propose: a short written design note settling the naming convention and
the unmatched lane, then the build against it, delivered with a one-page runbook
covering the manual single-invoice resend you asked for. Fixed price per phase —
I’d rather quote against the two decisions above than guess at them now.
I work fixed-price per deliverable, async, CET, written briefs over meetings.
If a $400–$650 custom build is more than you need: I shipped DispatchOnce — an importable Make + n8n pack that does the reliability piece people are quoting here (exact invoice-ID match, hold-back if 0 or multiple PDFs including (1) duplicates, skip DRAFT, write sent/error back to the Sheet, second run sends nothing, Resend flag). Drive not desktop — same constraint everyone already flagged. Not invoice generation. Polar $19 one-time, zip includes a fixture folder (happy path / missing PDF / duplicate). Checkout: https://buy.polar.sh/polar_cl_BJS81OzDY2vLcexoWYCT21UQFlEVtZcLdahM53BQHkk — I am the author. One reply, not a quote for custom work.
Hi! I saw your post about automating PDF invoice emailing with Make.com.
I’ve already built Make workflows using Gmail, Google Sheets, Google Drive and AI, so this is very close to my existing experience.
I’d be interested in helping you build this. I can first review your current invoice process and suggest the simplest workflow before we start.
Hi Andrew, if this is still open, my proposed fixed price is US$200 for the Google Sheets + Google Drive + Gmail version, with a target of two business days after we agree the fields, file naming and access.
The first US$75 milestone would demonstrate three test invoices as Gmail drafts: correct recipient, PDF and subject; correct mid/end-month selection; and a missing or ambiguous PDF held for review. That payment is credited toward the $200 total. The remaining work covers the approved send path, sent/error tracking, controlled individual resends, and a written operator guide. Live client emails would require your approval after testing.
One detail I’d include in the design: if Gmail may have accepted an email but Make loses the response, the invoice goes into a reconciliation state rather than being blindly retried. A simple “sent” checkbox alone cannot prevent that duplicate.
Here is a public code sample of retry/recovery work with regression-test results: AI Firm work sample: asynchronous initialization recovery and cancellation regression tests · GitHub
I use AI-assisted engineering. Please DM the Sheet column names and two anonymized PDF filenames if you’d like to agree the first milestone. The quote assumes PDFs are already available in Google Drive; desktop/iCloud syncing would need separate scoping.
Arda / AI Firm / [email protected]
