Why Most AR Automation Stops at the Email Reminder and Who Goes Further

Most AR automation schedules reminders, while stalled invoices need decisions and follow-through. An AI-powered AR team handling Coupa and Ariba submissions end-to-end must submit invoices, interpret rejections, correct them, resubmit, and confirm receipt inside the portals. The dividing line is execution.

Why dunning logic is built to solve the wrong problem

A standard dunning engine checks how long an invoice has been past due, sends a template, waits a set time, and sends another. Eventually, it escalates. The next action follows from the date rather than an assessment of why payment has not arrived. That makes dunning a scheduling system, with a defined trigger and a predetermined response. Its job is to keep the reminder calendar moving.

That design genuinely helps when an invoice is late because someone forgot to pay it. A nudge can clear simple inattention without involving a collector. The limit appears when the invoice is disputed, a document is missing, the contact has changed, or payment arrived but was never applied. Those conditions require reasoning to read the situation and choose a different action.

What actually sits behind a standard dunning cadence

An active dispute over an invoice needs to be settled, and another reminder can hurt the relationship without getting the customer any closer to paying. A short payment leaves an open balance that may have no recorded explanation. An unapplied payment creates a different mismatch altogether. The customer has paid, but the receivable still looks open, so the engine keeps chasing a settled debt.

Other exceptions concern information the cadence does not have. A customer may have promised to pay during a call or an earlier email, yet the system sends another reminder because that commitment was never recorded. A contact may have left, so each follow-up goes to the same dead address. Persistence is not much use against an abandoned inbox. Meanwhile, when a buyer requires submission through Coupa or Ariba, the work needs to happen there, because more messages outside the portal will not help.

Even a reminder that reaches the right person can create work the cadence cannot finish. The reply may contain a question, a dispute, a request for documentation, or confirmation that payment has already been sent. That reply then waits in a shared inbox for someone to interpret it and act. The conversation has two sides, but only one is automated. More outbound activity can therefore increase the manual burden on the inbound side, even while the reminder dashboard looks admirably busy.

Why rule-based systems structurally cannot handle this queue

A rule-based system evaluates a condition and fires the action attached to it. If an invoice is a certain number of days overdue, the system sends the corresponding template. This is a useful and predictable arrangement. It works when the condition tells the system enough to choose what to do.

Two invoices with the same overdue age can require opposite treatment. One needs a reminder, while another needs its reminders paused because a dispute is active. A short payment might come from a valid deduction or an error, and the balance left to pay does not show which. The system needs context from the customer’s explanation and the relevant records before it can select the next step.

A predetermined action can respond to a known condition, leaving an inbound email’s intent and the choice between correcting a document and resubmitting it unresolved. The architecture was suited to the work it was built to handle. The rules engine needs to be evaluated for its fit across the full scope of collections work. A more elaborate calendar is still not a judgment.

Where supplier portals create a collections problem that email cannot reach

For companies selling to large buyers, getting an invoice correctly into a procurement portal can be more consequential than the reminder cadence. More buyers now require submission through systems such as Coupa and SAP Ariba, each with its own PO-matching logic, submission formats, and rejection codes. Email sits outside that required route. A collector can send perfectly timed reminders while the invoice still needs work inside the buyer’s system.

A rejected submission generates a notification inside the portal that someone must log in, read, interpret, and act on. The rejection reason determines the repair. A PO number mismatch requires coordination with the buyer’s procurement team, while a format error requires a corrected file. A missing document calls for retrieval and resubmission. Those steps are not interchangeable, so a generic instruction to “try again” is no substitute for understanding what failed.

This is also where claims about portal automation need precision. Submitting an invoice is one capability, while interpreting a rejection and completing the corrective sequence is a broader one. Logging in, correcting submissions, and following their progress all sit outside email-based dunning. A service that handles Coupa submissions on an AR team’s behalf must therefore do more than tell that team a portal task is waiting.

What it actually takes to move an invoice that has stalled

For evaluation purposes, the useful test is whether a system can complete a context-dependent sequence without a human initiating each step. A disputed invoice gives that test a concrete shape. The system needs to read the dispute reason, get the supporting documentation, and send the case to the right internal owner with the context they need. It also needs to track the resolution timeline against the customer’s claim window. Recognizing the word “dispute” is only the starting point.

A portal rejection requires a different sequence of capabilities. The system must identify the rejection code, determine the corrective action, execute the fix, and resubmit through the portal’s own interface. It must then confirm receipt. That last step distinguishes an attempted submission from a completed handoff. When a platform instead sends an alert asking the AR team to make the correction, it has organized the work and left the correction to the AR team.

Inbound document requests test whether the system can act across the billing record and the conversation. It needs to retrieve the correct document from the billing system, attach it, respond, and log the interaction against the invoice. A promise to pay needs a different kind of memory. The commitment must be recorded and the cadence paused, with follow-up on the committed date if payment has not arrived and escalation if it remains unpaid.

If unreadable or ambiguous remittance prevents a payment from being matched, collections can continue chasing an invoice that has already been paid. Invoice-number lookup alone does not cover that ambiguity. Rillet’s AR automation guide describes how its machine learning cash application handles partial payments and missing remittance data and posts matched transactions straight to the GL. That capability is consistent with the straight-through match rates above 90% reported by leading AR automation platforms, though the figure is not a stated rate for Rillet itself.

How current tools split along the execution line

The useful dividing line among AR automation tools in 2026 is whether the software takes the next action or leaves it on a worklist. Price and ERP coverage do not answer that question. Execution can include sending outreach, responding to billing emails, posting cash, submitting invoices to portals, or gathering dispute backup. A platform may execute some of these tasks without handling all of them. Comparisons therefore need to stay at the workflow level rather than treating “AI-powered” as a complete job description.

Paraglide is positioned as an AI-native AR platform for inbound query resolution and outbound collections. Its agents read incoming billing emails, get live account data, and answer standard queries without help from a person. They also manage multi-turn collections conversations from first outreach through payment. Its described fit is the conversation layer on both sides of the reminder. That includes invoice copy requests, PO number queries, payment confirmations, and follow-ups on prior threads.

Paraglide uses a human-in-the-loop to handle amount discrepancies and dispute notifications, so people still take part in those cases. That boundary is useful to know. It distinguishes routine queries the agents resolve from exceptions requiring people in the process. Its stated capabilities establish more than outbound scheduling, but they do not establish end-to-end Coupa or Ariba submission.

Rillet is an AI-native ERP with AR automation built into the accounting layer. Its Aura AI agents handle workflows and post matched payments directly to the GL in real time. The system has invoicing, cash application, collections, and revenue recognition in one place. It is described as a fit for companies that want those functions built into their accounting system.

The range of accounting work Rillet handles does not, on its own, show that it can submit invoices through portals either. These are different jobs. The available capability descriptions support a comparison of inbound collections execution and accounting-layer execution, but not a named recommendation for full Coupa and Ariba handling. That distinction prevents a broad product category from becoming an unsupported promise.

How to tell whether a platform actually executes or just organizes

In a demo or formal vendor evaluation, the practical approach is to ask what happens after the routine reminder stops being enough. When a customer replies, does the platform read the response and take action, or does the message go to a shared inbox? The handoff reveals the boundary. If the inbox is the answer, the platform automates outbound communication while leaving the reply layer to people.

Does the platform submit invoices to Coupa and Ariba, or notify the AR team to submit them? For end-to-end handling, the evaluation also needs to cover rejection interpretation, correction, resubmission, and confirmation of receipt. Submission alone is not the whole workflow. A buyer who wants someone to handle Coupa for the team needs to know who does each of those steps, especially when the first try fails.

Disputes and payments provide two further tests. When a dispute is logged, does the system retrieve documentation, route it with context, and track the resolution window, or simply add another item to a worklist? For cash application, is matching straight-through, or does a person need to review every unmatched payment? Partial and multi-invoice payments expose the depth of the matching capability. High match rates on those cases indicate more than rules that work only when an invoice number arrives neatly attached.

The final question concerns the audit trail. Systems that do the work need to log every action they take, every reply they send, and every portal submission in a form that finance can review. A priority score may help a collector decide which invoice to call about next, leaving the human work required on that invoice and the need for that record unchanged.

The right fit still depends on the workload. A company that invoices a few clients on simple terms may be able to handle its exceptions by hand without more automation. The case grows stronger as invoice volume, customer complexity, and portal exposure increase. For any demo or formal vendor evaluation, the usable checklist is whether the platform handles replies, completes portal work, advances disputes, applies cash, and records its actions. The decision then rests on which of the team’s actual tasks it finishes, and which it hands back.