I built an invoice-reminder prototype that checks outstanding invoices, identifies overdue balances, sends customer reminders, and records each successful follow-up. If an invoice remains unpaid after three recorded reminders and a further waiting period, the workflow notifies the accounts team for personal attention.
The project demonstrates the decision and notification logic using Google Sheets as its invoice source. A client implementation would connect to the business's accounting or payment system so invoice balances and payment status can feed the workflow without maintaining a separate spreadsheet. That integration has not been built or tested in this project.
The practical goal is to answer three questions: Which invoices need a reminder? Has enough time passed since the last message? Which accounts now need a person to follow up?
1. Business brief
The business problem
Sending an invoice does not finish the collection process. Someone still needs to check whether its deadline has passed, confirm what remains outstanding, look for earlier reminders, and decide whether another email is appropriate.
When these checks depend on staff reviewing records manually, routine follow-up can consume time and become inconsistent. A customer might receive repeated messages too close together, while another overdue account receives no attention. Staff also need a way to pause reminders during a dispute or an agreed payment arrangement.
This approach is most useful where a business has a specific gap in its current follow-up process. If its invoicing software already provides suitable reminders and escalation, duplicating those messages would add little value.
The solution built
The prototype reads invoice records and checks four conditions: the invoice is marked Unpaid, its outstanding balance is greater than zero, its due date is before today, and reminders are not paused.
It then checks reminder history. An invoice can proceed if no previous reminder is recorded or at least 72 hours have passed since the last one. Below the three-reminder limit, it sends a customer email and updates the invoice's reminder count and timestamp.
At or above the limit, it checks whether the accounts team has already been notified. If not, it sends an internal follow-up email and records an escalation timestamp. This makes routine follow-up automatic while leaving payment verification, disputes, and collection decisions with people.
The workflow does not create invoices, collect payments, charge customers, read replies, or independently verify bank receipts.
2. The working workflow
| Step | Plain-language explanation |
|---|---|
| 1. Start the check | A daily 9 AM schedule is configured. A connected Manual Trigger also allows test runs. |
| 2. Read the invoice list | Read the records from Invoice Reminder Tracker, Sheet1, including payment status, balance, due date, and reminder history. |
| 3. Find invoices that need attention | Continue only for unpaid, overdue invoices with money still owed and reminders allowed. |
| 4. Avoid contacting the customer too soon | Check whether no reminder has been recorded or at least three full days have passed since the last one. |
| 5. Check the reminder limit | If fewer than three reminders are recorded, continue to the customer email. Otherwise, continue to the internal follow-up branch. |
| 6. Send and record a customer reminder | Email the customer their invoice details, then increase the count and save the reminder time against that invoice. |
| 7. Notify the accounts team when needed | After the reminder limit and waiting period, send staff the unresolved invoice details if no previous escalation is recorded. |
| 8. Record the internal notification | Save the escalation time so the same invoice does not repeatedly notify staff during normal later runs. |
In everyday terms: the automation checks who is late paying, sends a polite reminder when appropriate, remembers that it sent it, and hands persistent overdue balances to the team.
The export contains eleven connected nodes: Manual Trigger, Schedule Trigger, Read Invoices, Invoice Needs Reminder, Reminder Due, Below Reminder Limit, Send Invoice Reminder, Record Reminder Sent, Not Yet Escalated, Notify Accounts Team, and Record Escalation. Both triggers connect to Read Invoices; each starts its own execution.
3. Reminder logic explained
All four eligibility conditions must pass. Being unpaid alone is not enough: the payment deadline must also have passed.
| Invoice situation | Workflow decision |
|---|---|
| Unpaid, overdue, positive balance, reminders allowed | Continue to the reminder-history check. |
| Paid | Stop before sending an email. |
| Outstanding balance is zero | Stop before sending an email. |
| Due today or in the future | Exclude under the intended overdue-only rule. |
| Reminders paused | Stop before sending an email, even if overdue. |
| Last reminder was less than 72 hours ago | Wait for a later eligible run. |
| Fewer than three reminders, waiting period satisfied | Send a customer reminder and record it. |
| Three or more reminders, waiting period satisfied, no escalation recorded | Notify the accounts team and record it. |
| Escalation already recorded and reminder limit reached | Do not repeat the internal notification. |
The waiting period is a rolling 72-hour check, not simply a change of calendar date. A daily run sends only when that period has elapsed, so a reminder may occur later than exactly three days after the previous one.
Because the waiting-period check comes before the reminder-limit check, escalation also waits at least 72 hours after the third recorded reminder. It is not sent immediately alongside the third reminder.
For example, an invoice with an overdue balance of 500 receives its first reminder. An immediate rerun sends nothing. If it remains eligible, later runs can send the second and third reminders. After the final waiting period, the accounts team receives an internal notification instead of a fourth customer reminder.
4. Tracker, records, and email behavior
The current sheet combines sample invoice inputs and workflow-generated follow-up history.
| Information | Maintained by |
|---|---|
| Invoice ID, customer name, and email | Supplied as sample data; intended to come from business records. |
| Invoice date and due date | Supplied in the invoice source. |
| Outstanding amount and payment status | Manually maintained in this prototype; a client integration would supply current payment information. |
| Payment link | Optional existing link supplied by the business; the workflow does not create one. |
| Reminders paused | Controlled by the business for exceptions such as disputes or payment arrangements. |
| Reminder count | Increased after a successful customer email action. |
| Last reminder sent at | Recorded after a successful customer email action. |
| Escalated at | Recorded after a successful accounts-team notification. |
Rows are matched by invoice ID. The reminder-recording node changes only the count and last-reminder timestamp, while the escalation node changes only the escalation timestamp. Payment status and balances are not changed by these actions.
This tracker is a spreadsheet, not a separate accounting application or payment portal.
The customer email includes the customer's name, invoice number, due date, and outstanding amount. When a payment link exists, the message includes it. Otherwise, it directs the customer to the payment details on the original invoice. It also asks customers who have already paid to reply with a payment reference for staff to review.
The internal email includes the invoice and customer details, outstanding balance, reminder count, and last-reminder time. It asks the accounts team to review payment records and personally contact the customer if payment is still outstanding.
Recorded counts and timestamps control future decisions. The three-reminder limit stops further customer reminders while the count remains at or above three. The escalation timestamp suppresses another internal notification on that branch.
These checks reduce repeated messages during normal sequential runs. They do not guarantee exactly-once delivery under every failure condition. If an email sends but the spreadsheet update fails, a later run may repeat it. Overlapping executions can also read the same old history before either saves its update.
5. Test evidence
The results below are based on the reviewed workflow export, execution screenshots, and email and spreadsheet checks confirmed during the build.
| Test | Observed result |
|---|---|
| Read sample invoices | Three invoice records were returned. |
| Identify overdue unpaid invoices | INV-001 passed; the paid invoice and future-due invoice were excluded. |
| Handle accidental text spaces | Adding trim operations to the payment-status and pause checks resolved the observed mismatch. |
| Send the first reminder | The received email contained INV-001, its due date, and its outstanding amount. |
| Record the reminder | The update returned reminder_count of 1 and a last-reminder timestamp for INV-001. |
| Immediately repeat the workflow | Execution stopped at Reminder Due's False branch without another customer reminder. |
| Simulate the reminder limit | Setting the test count to three and using an older reminder timestamp triggered the accounts-team email and recorded escalation. |
| Repeat the escalation test | The invoice followed Not Yet Escalated's False branch without repeating the notification. |
| Mark the test invoice paid | Updating its status to Paid and balance to zero excluded it at the initial check. |
| Pause an overdue invoice | An unpaid invoice with a positive balance and reminders_paused set to Yes was excluded. |
The tests demonstrate the prototype's main paths with sample data. The three-reminder history was simulated for the escalation test; three actual reminders spaced over multiple days were not documented. Live accounting synchronization, unattended scheduling, due-today timezone boundaries, concurrent executions, invalid records, and service-failure recovery were not tested.
6. Where this approach may help
These are potential applications, not claims of deployments or measured results for these businesses.
| Business type | Where this approach may help |
|---|---|
| Marketing, design, and web agencies | Following up on overdue project installments and monthly retainers. |
| IT service providers and consultants | Checking outstanding service invoices and handing unresolved balances to an account manager. |
| Plumbing, electrical, and HVAC contractors | Following up on invoiced work after the agreed payment deadline. |
| Commercial cleaning and landscaping companies | Managing repeated follow-up across recurring service customers. |
| Bookkeeping and accounting firms | Monitoring their own client fees or adapting the process for an authorized client's receivables. |
| Engineering and architectural practices | Tracking overdue professional fees and milestone invoices. |
| Wholesalers and distributors | Reviewing overdue business-customer invoices issued on payment terms. |
| Equipment rental and event businesses | Following up on overdue deposits or balances, with timing adapted to their booking policies. |
| Property maintenance and management service businesses | Following up on their own service-fee invoices; rent collection would require separate rules and review. |
The best fit is a business with enough invoice volume to make manual checking repetitive, accurate payment records, and a follow-up need its current tools do not already meet. Timing, tone, and escalation ownership should be agreed for each business.
7. Human responsibilities and planned integration
The automation handles repetitive record checks, reminder timing, customer emails, internal notifications, and follow-up history updates.
In this prototype, a person still maintains invoice and payment data in Google Sheets. In a connected client implementation, the business's accounting or payment system would supply those changes. Reliable source data remains essential: the workflow cannot know about a payment that has not reached its input records.
People remain responsible for confirming receipts, resolving disputes, handling replies, agreeing payment plans, and deciding how to pursue unresolved balances. Staff can pause reminders without deleting the invoice history. The workflow does not automatically resume paused invoices or decide when an escalation has been resolved.
The intended client service is: your invoice system supplies current balances and payment status, routine overdue reminders run automatically, and your team receives the accounts that need personal attention.
To deliver that service, implementation would need to: establish an authorized connection to the client's chosen accounting or payment platform; confirm how that platform represents outstanding balances, partial payments, paid invoices, void invoices, and disputed accounts; map stable invoice identifiers and customer contact information to the follow-up records; read current invoice and payment data without requiring a duplicate manually maintained spreadsheet; preserve reminder history separately where needed so source updates do not reset counts or timestamps; recheck payment and pause status close to sending to reduce the risk of contacting a customer whose account changed during processing; and test the rules, emails, record updates, and failure recovery with the client's data before activation.
The current reminder and escalation logic provides a foundation for this work. Integration availability and the correct data mapping must be verified for the client's actual system.
8. Deployment and practical limits
The export is inactive. Its Schedule Trigger is configured for 9 AM, but no workflow-specific timezone is saved. Deployment would set the client's timezone, verify due-date handling around midnight and daylight-saving changes, and publish the workflow on an environment that remains running.
The current design assumes unique invoice IDs, valid dates and amounts, and consistent text values. The eligibility rule specifically expects Unpaid and No after trimming spaces; other status labels require mapping. A partially paid invoice can proceed only if its remaining balance and status are represented in a way that meets these rules.
Malformed nonblank reminder timestamps can prevent an invoice from becoming eligible. Missing or invalid fields need explicit validation and exception handling before client use. The prototype reads payment status at the start of a run; it does not perform a separate payment-status lookup immediately before each email.
There is no custom failure-notification workflow or recovery mechanism for an email that sends but fails to be recorded. Reminder history should not be manually reset without understanding that doing so can permit additional messages.
Client setup would configure credentials, source records, recipients, sender identity, currency formatting, and reminder policies. The current email displays the amount without a currency label. The exported JSON contains configuration references and a test recipient, so it should be sanitized before public distribution.
9. Results and business value
The demonstrated result is a working prototype that selects eligible overdue invoices, sends and records customer reminders, respects a waiting period and reminder limit, and records an internal notification for unresolved accounts. It also excludes paid, future-due, and paused invoices under the tested conditions.
Potential value comes from reducing repeated invoice checks and email preparation, giving staff consistent follow-up history, and directing personal attention to accounts that need it. These improvements may reduce administrative effort and support timely collections. No client time savings, cost reductions, or collection improvements have been measured in this project.
A client pilot could measure staff time spent following up, the accuracy and usefulness of reminders, duplicate-message frequency, and how quickly escalated accounts receive attention. Those results would establish the value for that business.
To adapt overdue invoice monitoring, reminder timing, and accounts-team follow-up to your invoicing process, discuss a similar project.