ACCOUNTS RECEIVABLE · OCTOBER 2026
A reminder is useful only when the invoice is still due.
Use an invoice-chasing agent to prepare evidence-based follow-ups and coordinate exceptions. Keep the ledger authoritative, refresh invoice state immediately before sending, and separate drafting from permission to contact the customer.
Define the receivables job precisely
This guide concerns accounts receivable: money customers owe your business. It is different from an accounts-payable invoice processor that approves supplier bills. The workflow’s job is to identify eligible overdue invoices, understand known exceptions, prepare an appropriate next step and preserve a clear collection record.
Write the eligibility rules before configuring n8n. Define supported entities and currencies, overdue age, approved contacts, dispute exclusions, promise-to-pay handling and maximum contact frequency. Exclude accounts under legal review or requiring a relationship manager. Treat the AI as an interpretation and drafting component within those rules.
A chatbot may answer a collector’s question. An agent workflow can retrieve current state, choose a permitted branch and create a controlled task or communication. Neither label establishes ROI. The useful result is a correct follow-up or exception handoff, measured against the existing collections process.
Build the workflow in nine explicit steps
One: schedule a run and create a run ID. Two: retrieve open receivables from the accounting system using an appropriate read scope. Three: filter eligibility with deterministic rules. Four: join approved contact details, prior reminders and dispute records. Five: retrieve the relevant collections policy.
Six: ask the model to classify the case as reminder, promise follow-up, dispute, missing information or manual review. Require evidence references and a draft, with no invented invoice amount or payment date. Seven: validate the output and apply approval rules. Eight: refresh the ledger and contact state immediately before sending or creating the collector task. Nine: write the action result to the collection record and update the workflow state.
Xero’s official Accounting API specification illustrates the difference between reads, accounting mutations and their OAuth scopes. Use the scope required for the actual operation; an email-reminder workflow does not need unrestricted accounting writes simply because an integration offers them. Xero Accounting API specification
Represent payment promises and disputes as state
An invoice can be overdue and still inappropriate for another generic reminder. Maintain states such as eligible, disputed, promised, review_pending, sent, paid and suppressed. Store the evidence for transitions: a ledger payment, a customer promise, a collector decision or a policy rule.
For a promise to pay, record the customer’s actual date and message reference. Do not let the model infer that payment arrived because the customer used reassuring language. For a dispute, create a case with the reason, owner and requested evidence; suppress routine reminders until the policy allows them again.
Keep the immutable invoice ID alongside the display number. Similar invoice numbers across entities should not collide. Record currency and amount as structured values. The model may adapt tone to context, but the amount, due date, payment link and recipient must come from validated fields.
Make approval and duplicate protection concrete
Use an action key tied to invoice ID, communication stage and policy version. Before sending, check whether that action has already succeeded. If the send call times out, inspect the mail provider or action record before retrying. Workflow retries should not automatically resend a message to a customer.
Require review for disputed balances, changed recipients, material amount changes or sensitive escalation language. An approval refers to an exact draft and current invoice state. If the balance changes after approval, invalidate the draft and prepare a fresh one.
n8n’s v2 documentation describes execution, security and save/publish changes; those are operational migration considerations rather than evidence of faster collections. Check them against the version you deploy, keep credentials separate from prompts and test a recoverable failure path before scheduling unattended runs. n8n migration guidance
Measure collections without inventing causality
Track reminders prepared, approved, suppressed, delivered and reopened. Measure collector review time and erroneous contacts. Separately track overdue balances and days sales outstanding with the same accounting definition and business perimeter over time.
Cash collected after a reminder is not automatically cash caused by the agent. Customers may have paid anyway, and sales mix or payment terms may change. Where feasible, compare similar cohorts or a staged rollout, documenting exclusions and seasonality. Do not attribute an aggregate DSO improvement to the tool without a credible comparison.
For operating cost, include the workflow execution plan, model input and output, email delivery, exception review and maintenance. n8n’s cloud plans describe execution quotas, not unlimited executions. Use observed run and retry volume to budget; a historical flat-cost assertion is insufficient. n8n pricing; API pricing
Compare the choices
| Case | Allowed next step | Evidence required |
|---|---|---|
| Overdue with no exception | Prepare approved reminder | Current balance, contact and reminder history. |
| Promise to pay | Schedule promise follow-up | Explicit customer date and original message. |
| Dispute or credit pending | Create collector case | Dispute record and assigned owner. |
| Payment received or balance changed | Suppress or regenerate | Latest ledger state before contact. |
Worked example: make the decision concrete
Illustrative case: invoice INV-204 is overdue by ten days. The initial batch shows a balance of $2,000 and no recorded dispute. The agent drafts a reminder, but before sending its final ledger check finds a $2,000 payment. The correct result is suppression with the payment reference, not a successful-send metric.
In a second variant, the customer promises payment next Friday. The workflow stores that exact promise and creates a follow-up date under policy. If a timeout occurs after a reminder is delivered, the action record prevents a duplicate. These scenarios test collections quality without pretending that a fictional company reduced DSO or recovered a particular sum.
Failure modes to plan for
The most damaging failures are contacting the wrong customer, chasing a paid invoice and escalating a disputed balance with inappropriate language. Prevent them with object identity checks, current-state reads and explicit exception routing.
Other failures include timezone errors, duplicate contact after reruns and confusing credit notes with cash payments. Assign a collector to review exception queues daily and document a stop switch. A unattended workflow that cannot be paused promptly is unsuitable for customer-facing collections.
Your useful next step
Build a draft-only run on one entity and reconcile every proposed reminder to the ledger. Test paid-before-send, disputed balance, duplicate event, changed contact and mail timeout. Enable sending only for a narrow approved case class after those results are correct.
Questions and answers
Can the agent change invoice amounts?
Keep the chasing workflow read-only in accounting by default. Any adjustment should follow a separate authorized accounting process with its own controls and evidence.
How do we prevent chasing a paid invoice?
Refresh the ledger immediately before contact, compare it with the approved draft, and suppress or regenerate the action if the balance or status changed.
Does approval mean the workflow is not an agent?
No. The workflow can interpret evidence and choose a permitted branch while requesting approval for the communication or escalation.
How can we prove value?
Measure correct contacts, suppressed errors, collector workload and costs. Evaluate collection outcomes using a documented baseline or comparable rollout rather than assuming every later payment was caused by the agent.
Sources and evidence scope
Primary sources checked on 11 October 2026. Product pages establish vendor-described features; they do not establish independent comparative performance. Worked examples are explicitly illustrative. Implementation recommendations are editorial guidance.
- Xero Accounting API specification — Official specification defines invoice and accounting operations, OAuth scopes and idempotency-key parameters for supported mutations.
- N8N V2 — Official v2 migration documentation supports save/publish and execution/security changes; it does not validate invoice ROI claims.
- N8N — Starter shown at €20/month billed annually for 2.5K workflow executions with unlimited steps; unlimited steps are not unlimited executions.
- Openai Prices — API cost requires separate input/output, caching, tool charges and actual usage.
Research Path