The difference between AR automation and an AI AR agent is context

Vendors have settled on the word agent, and buyers hear it as a claim about autonomy. That is the wrong axis. What separates AR automation from an AI AR agent is how much the software knows before it does anything.

Context is what turns an action into an outcome. Software without it still acts. It acts blind, and it does so on schedule.

A rules engine acts on one number

Days overdue. Possibly a segment you assigned at setup. That is the entire basis on which a dunning tool decides to contact your customer.

It has no view of anything else in the business. It cannot see that the invoice was disputed three weeks ago in an email thread, that a credit note was promised on a call in May, that the same customer settled four other invoices on Tuesday, that procurement rejected the submission in Ariba for a bad PO number, or that the account is two weeks from signing a renewal worth forty times the balance being chased. None of that sits in the field it reads.

So it acts, confidently, and often wrongly.

The chase goes to a customer who paid last week. The firm escalation lands on a buyer who is waiting on your credit note. The final notice arrives at an account your commercial team is mid-negotiation with. Each of those is correct against the rule and wrong against the situation.

The reminders go out on time and land badly. You have taken away manual work without changing the outcome, which is what teams a year into a dunning rollout usually report. Effort down. DSO where it was.

Better emails, different triggers

Most AI in receivables only writes the email. The decision to send it is still a rule you set up months ago. Day 7 a nudge, day 14 something firmer. The AI makes that reminder read better. It does not change when it goes out.

Spinal makes the decision itself. Before it sends anything it looks at the customer: how risky they are, how late they normally run, whether they reply to email, whether they answer the phone, whether WhatsApp gets a response, and what their payment history says about whether the money is actually coming.

Out of that it decides three things. Whether to chase at all, when, and on which channel.

Take a customer who always pays on day 45 and has never missed one. A rules engine reminds them on day 14 and annoys them for nothing. Spinal waits.

Another has ignored six emails this year, then paid the day after someone rang. The rules engine queues a seventh email. Spinal rings.

What the ledger cannot see: Why?

Your ledger tells you an invoice is unpaid and how late it is. It does not tell you why.

The reason is almost always somewhere else. A query the customer raised by email that nobody closed. A remittance that paid four invoices and short paid the fifth without explaining. A submission stuck in Coupa or Ariba. A proof of delivery sitting in a transport system. A promise to pay made on a call six weeks ago. A credit note a colleague agreed to and never raised. What the same customer owes your other entities.

Someone on your team could find all of that for one invoice in about twenty minutes. With four thousand open invoices, nobody does. It gets done for the biggest balances and nowhere else.

More context = better decisions = paid faster

Every decision about an invoice is only as good as what was known when it was made. Someone who reads the account history before picking up the phone gets a different result from someone who reads only the balance. Software is no different, and for thirty years software had access to the balance.

This is the part that genuinely changed, and it is not the writing. Reading unstructured material at volume, thousands of email threads and PDFs and portal states, and turning it into a working view of what is happening on each account, was not possible before. Generating a nicer chaser always was.

An agent that gathers context and then acts produces different actions rather than faster ones. Sometimes the right action is to send nothing, which no cadence will ever decide on its own.

What that looks like in Spinal

Most AR tools wait for problems. Spinal goes looking for them.

Spinal reads before it acts, and it reads two things.

The first is your email, meaning the actual communication between your business and the customer. That is where the query was raised and never closed, where the credit note was promised, where someone agreed different terms on a Friday afternoon and never told finance. It also shows who genuinely replies at that customer, which is often not the contact the invoice was addressed to.

The second is your ERP. Entities, customers, invoice amounts, due dates, payment terms and the ledger behind them. Which of your legal entities raised the invoice, what else that customer owes across the rest of the group, what they have paid before and how late they paid it.

The ERP holds the record of what is owed. The reason it has not been paid is almost always sitting in an email thread. Spinal joins the two, so the picture it works from is the invoice together with the conversation attached to it.

Going looking means the blocker gets found before the invoice ages into a problem. An invoice heading for a rejection on a bad PO number gets a corrected submission rather than a reminder at day 14. One blocked on proof of delivery gets the document retrieved and attached. One where the customer is waiting on a credit note gets the credit note chased internally rather than the customer chased externally. One that is genuinely just late gets a chase written from the history of the account, in a tone that reflects what has already been said.

The manual work still goes away. The difference is that the outcome moves with it.

‍