Accounts Receivable Automation: Which Reminders to Send

Accounts receivable automation uses software to handle customer invoicing, payment follow-up, cash application, and related record updates. For a small B2B finance team, a useful first project is often narrower: prepare the right payment reminders from current invoice balances, payments, disputes, and customer commitments.

My recommendation is to automate that selection before increasing message volume. A due date tells you when an invoice became overdue. It does not tell you whether the customer has already paid, disputed a charge, or agreed on another follow-up date.

The example below turns five overdue invoices into three reminders totaling $3,100. The important result is not fewer emails. It is knowing why that amount is appropriate—and what work remains outside the batch.

Five overdue invoices do not necessarily mean five reminders

Consider five independent customers, each with one USD invoice. All invoices are past their original due dates. This is a synthetic example, not a KelenAI client result or a test of any AR product.

The invoices originally totaled $6,000. One $200 credit has already been approved and posted, leaving $5,800 in open invoice balances before applying the payment described below.

For this illustration, finance permits requesting an undisputed portion separately and pauses ordinary reminders during an accepted, unbroken promise to pay. Those are chosen business policies, not universal collection rules.

The proposed batch is B201 $1,800 + D401 $300 + E501 $1,000 = $3,100, subject to a fresh status check before sending.

The other $2,700 of open invoice balances is not one undifferentiated “hold.” It consists of a $1,000 payment awaiting application, a $200 dispute needing resolution, and a $1,500 promise requiring later review. Each needs a different next action. The posted $200 credit separately explains the difference between the original $6,000 and the current $5,800.

None of those exclusions is evidence of $2,900 collected, saved, or written off. A promise is not cash. A dispute is not an approved credit. Suppressing a reminder for A101 does not itself settle the invoice.

This separation exists in real accounting products: Microsoft’s collections workspace distinguishes disputed invoices, promised payments, and payments posted but not yet settled against an invoice. The table above is our illustrative selection policy, not a claim that this exact behavior is enabled in your system.

What should happen to the two paused reminders?

For A101, the cash-application owner should confirm the payment’s identity, allocation, and accounting result. If the payment is only a similar amount from an uncertain payer, that is weaker evidence: investigate rather than mark the invoice paid or silently substitute another invoice. Our cash application guide works through that matching problem.

For C301, preserve the promised amount, date, responsible collector, and next review date. Leave the receivable visible. Oracle’s promise-to-pay documentation distinguishes a commitment from its fulfillment or a broken promise; recording a promise is not recording receipt of money.

A pause without an owner or return date can turn an accurate suppression into forgotten work. The automation should produce both the reminder batch and the remaining work—not just hide the difficult customers.

Change the policy, and the correct batch changes

Two reasonable businesses can make different decisions about B201.

If finance requires a whole-invoice pause during any dispute, exclude B201 entirely. The batch becomes D401 $300 + E501 $1,000 = $1,300 across two customers, not $3,100. That may fit a contract or relationship policy better than requesting the undisputed portion. Software should follow the authorized choice, not quietly optimize for the larger amount.

Now return to the original partial-dispute policy. Suppose C301’s promise date passes and the collector confirms no payment arrived. If the next authorized action is an ordinary reminder, adding C301 produces $4,600 across four customers. A broken promise may instead call for personal follow-up; the date alone does not authorize a threat, fee, account restriction, or other escalation.

Finally, suppose A101’s payment is applied successfully. Its invoice balance falls to zero, but the proposed $3,100 reminder batch stays the same because A101 was already excluded. The change resolves an application task. It does not demonstrate that the reminder process collected another $1,000.

We independently checked these totals and changes using integer cents. They establish the consequences of the stated inputs and policies—not a collection rate, an AI accuracy score, or proof that one policy improves customer relationships. Actual accounting adjustments and collection policies belong to finance.

Build a reminder that can actually be sent

Use B201 to specify the positive path. The source invoice is $2,000, the open dispute is $200, and the authorized request is $1,800. A useful workflow must carry that distinction into the customer’s message.

Read the current customer and invoice records

Join the invoice to the correct customer, legal entity, currency, collection contact, due date, and open balance. Then retrieve current payments, applied credits, dispute scope, promises, and previous contact.

For this example, the collector should see B201, its $2,000 open balance, the $200 disputed line, the reason for that dispute, and the policy permitting a separate $1,800 request. A contact’s name alone is not enough to establish that they should receive another customer’s invoice details.

If dispute information lives only in a sales representative’s inbox, connecting that evidence may be the project. A more polished email generator will not fix a reminder built from an incomplete record.

Prepare a message that preserves the unresolved amount

An illustrative B201 message could say:

We’re following up on the $1,800 undisputed portion of invoice B201. The separate $200 charge remains under review with our team. Please confirm the payment status of the $1,800, or let us know if it has already been sent.

That is a draft for the stated scenario, not a universal collection template. Add your approved invoice reference, payment route, and contact details. Avoid saying “your remaining balance is $1,800”: the full invoice still has $2,000 open until the dispute is resolved or an authorized adjustment changes it.

For D401, the message should instead reference the current $300 balance after the posted credit. Reusing the original $500 invoice amount would defeat the purpose of connecting the accounting data.

Recheck before sending, then record what happened

Between draft preparation and dispatch, a payment can arrive or a collector can agree to pause contact. Re-read the consequential statuses before release. If the source is unavailable or the data conflict, leave the message for review rather than sending from an old export.

Use one recorded send attempt for the same customer, invoice scope, and reminder step. If the email service times out, first determine whether it accepted the message; blindly retrying can send a duplicate. Where the provider supports a request identifier or delivery lookup, use it and retain the result.

A payment can still arrive immediately after the final check. No isolated pre-send lookup eliminates that race. Keep the check-to-send interval short, process payment updates promptly, and provide a reply path for customers who have already paid. Do not promise that automation makes mistaken outreach impossible.

Record the recipient, requested amount, included invoices, policy reason, timestamp, and delivery result. A later reply saying “we dispute the freight” should enter the dispute path before the next reminder, not merely change the tone of another automated email. Detailed review design belongs in the human-review workflow guide; here, the collector needs enough evidence to resolve this customer’s next action.

Use native reminders, a data connection, or AI for different gaps

I would start with the accounting or billing product already holding the invoices. Native functionality may solve a simple recurring reminder task without a new platform.

For example, Stripe documents automatic reminders before, on, or after invoice due dates, along with one-off reminder options. Dynamics 365 Finance collections automation supports scheduled activities and emails, quiet days between contacts, and simulation of proposed actions. These are examples of available native capabilities, not evidence that either product implements every rule in our five-invoice case.

The next choice follows the missing information:

• Balances and exception states are already reliable in one product: configure and test its native reminder process first.
• Payments, disputes, or promises live elsewhere: connect those states before expanding automatic sending. Confirm that a change reaches the actual reminder decision, not just a dashboard.
• Customer context arrives as free-form correspondence: AI may help identify a dispute, extract a proposed date, or draft a response. Keep the source message available; a proposed promise is not automatically an accepted agreement.
• The bottleneck is negotiation or incorrect billing: improve that work. More automatic reminders can leave the underlying delay untouched.

A broader AR platform becomes reasonable when the current system cannot support recurring cross-system collection work and the benefits justify another operating layer. It is not automatically the right purchase for a few scheduled emails. Conversely, a simple scheduler is not enough if collectors routinely need several systems to decide whether a message is appropriate.

That is the native-first implementation approach applied to AR: retain functioning capabilities and solve the specific gap. AI is useful when interpretation is missing; it is unnecessary for subtracting a posted credit or checking a recorded due date.

Decide whether reminders solve your cash problem

Before starting, inspect a manageable set of overdue invoices and classify why the next action is delayed. Can the customer pay but needs a reminder? Is the invoice wrong? Has payment arrived without application? Is a dispute waiting for someone inside your business?

The example gives three very different projects: remind E501, resolve B201’s disputed charge, and finish A101’s application. A single “overdue” label cannot tell you which one deserves the first investment. If most delays come from missing delivery evidence, improving billing accuracy may matter more than reminder frequency.

Judge the reminder workflow on whether it selects the correct customers and amounts, gets approved messages out, and returns exceptions to an accountable person. Separately examine actual customer payments and application results. An email accepted by a provider is not money received, and money received is not automatically applied cash.

For the business case, count preparation and correction work as well as software and maintenance costs. Use the AI automation ROI guide to separate released staff capacity from expenses actually removed. Do not convert the $2,700 excluded from our example’s batch into financial savings.

AR is one part of order-to-cash automation. A bounded reminder workflow is useful when it closes a real follow-up gap; it is not a replacement for correct orders, billing, payment application, or reconciliation.

Submit one recurring AR workflow

Describe where your customer invoices, payment information, disputes, and follow-up notes currently live, plus one recurring decision your team struggles to make. KelenAI’s free workflow consultation request starts with that submission. We review the context and follow up if a focused conversation would help.

Please do not submit bank credentials, full account numbers, or confidential customer records. A description of the handoff is enough to start.