A couple of weeks ago I wrote about the least glamorous problem in finance: the cash that has already arrived but hasn't been applied. The money is in the bank. The invoice still shows open. So the aging report says a customer owes you money they've already paid, you chase them for it, and the number you take to the board overstates what's actually owed. If you missed that piece, it's here.

That one was about the problem. This one is about what we did with it.

Today we're launching the Cash Application agent on Stacks.

The part the category skipped

Cash application looks like a data-entry problem, so for thirty years the software treated it like one. Nicer queues, cleaner dashboards, better ways to see the work. The seeing got easier. The matching never moved. A person still had to figure out who sent the wire, which invoices it cleared, and how to post it so it tied out against both the bank and the ledger.

Those are judgment calls, not lookups. And judgment is exactly the part the old tools handed back to a human and called automation.

So that's what we built: a cash application agent that does the matching itself.

The matching

The agent reads a payment the way your best AR person does. It pulls open invoices and customer records straight from NetSuite, then weighs everything it has: the reference in the bank description, the amount against open AR, the payer name, how close the date sits to an expected payment. When a customer emails a remittance to a dedicated address, the agent reads it and matches off it. There are no OCR templates to build per customer. It reads a new format on first contact.

Clean payments match on their own. The cases worth caring about are the ones that don't: a wire with no remittance, a cheque covering six invoices, a short pay with no explanation. That's where most tools stop and open a queue. It uses the customer's payment history and your tolerance rules to propose the match anyway, and shows you exactly why it landed where it did.

When the answer isn't there yet

A lot of payments can't be matched the moment they arrive, because the thing you need hasn't shown up. The remittance lands two hours after the wire. The invoice posts later the same day. A credit note changes the open balance.

The old process leaves the payment in a queue until someone reworks it by hand. The agent watches for the missing piece and makes the match when it appears. By the time you reach close, what's left in the exception list is the genuinely hard stuff that actually needs a person.

Built for audit

An enterprise finance team needs this to hold up at audit. So the controls are built into every step, not bolted on after.

Every suggestion carries its reasoning in plain language, with a link to the source. "Matched on the invoice references in the remittance advice." You can open the document and check. You can override anything: change the invoice, split the amount, reassign the customer, adjust applied amounts at the line level. If you want a review step, nothing posts without the controller signing off. Every action is logged, timestamped, and attributed inside Stacks, not buried in a NetSuite system log nobody opens until an auditor asks.

There's a panel that shows what the agent has learned about each account. "This customer usually pays several invoices in one transfer." "This one is reliable when a remittance is attached." You can read it, star it, or correct it. The agent isn't asking for blind trust. It's something your team teaches.

The part only Stacks can do

Here is what makes this different from bolting another cash application tool onto your stack.

Cash application doesn't happen on its own. The moment a payment is applied, it feeds the bank reconciliation and the close. On Stacks those aren't separate products emailing each other. The bank rec sees the payment hub as a live data source. A missing payment surfaces as an issue on the reconciliation, linked straight to the unposted item in the AR queue. One click takes the AR person to that exact bank account's payments. They post. The reconciliation updates. The close team sees real cash status through the month, not at 11pm on day three.

NetSuite stays your system of record. We don't touch your ERP configuration. We add the intelligent layer in front of it and wire it into the close you're already running on Stacks. Reconciliation tools confirm your records match reality after the cash is applied. We are the step before that. We get the cash applied, accurately, so everything downstream is cleaner.

More than time saved

The hours your team gets back are the easy thing to measure. The real change is to how cash works in your month. Today cash application runs as a batch job: payments pile up, someone works through them, and the AR aging only tells the truth in the days right after a cleanup. The agent applies cash as it lands, so your numbers are accurate on a Tuesday, not only on close day. Your team moves from working a queue to handling the exceptions that are left.

And it goes live in days. It runs inside the close you already have on Stacks, so there's no separate implementation project and no per-customer templates to configure before you see results.

What changes

For the AR accountant, the day stops being a clicking marathon. Open the queue, review what the agent suggests, override what you don't, post what you trust. The hours that used to go into mechanical matching go to the exceptions and the customer calls that need a human.

For the controller, you can see who posted what and why without opening a system log, and you can hand an auditor the trail without building it the night before fieldwork.

For the CFO, the aging report gets closer to true. Cash posts through the month instead of in a day-three backlog, so the working capital number you report reflects money that already landed.

See it on real payments

On June 30, Albert is running a live demo of the Cash Application agent, alongside Christian Martinez on how to actually put AI agents to work in a finance team. It's free, 5pm CEST / 11am EST. You can register here.

The aging report has been quietly wrong for finance teams for a long time. This is where we start to fix it.