Matching customer payments to invoices with AI

How the bot works

Nine steps. The matching, the arithmetic and the tolerances are ordinary code and cost almost nothing to run; the model is only asked to read the remittance.

1. It picks up every payment that landed. The bank feed, a lockbox or BAI2 file, a card processor's batch, a payment portal export. One list of money that arrived, before anyone starts guessing what it was for.

2. It goes and finds the remittance. The detail is almost never on the payment. It is in an email to the AR mailbox, a PDF attached to it, a spreadsheet, a portal the customer expects you to log into, or whatever survived of the reference in the bank description. The bot looks in all of them and says which one it used.

3. It works out who paid. By the invoice numbers on the remittance first, then the paying account, the name on the payment and how this customer has paid before. A payment from a parent company, a franchisee or a factoring house is named as such rather than being forced onto the closest-sounding account.

4. It proposes the allocation, invoice by invoice. Exact matches first. Then the real cases: one payment covering a dozen invoices, one invoice settled by two payments, a payment that matches a set of invoices only once a credit is included. Each proposed line says which invoice, how much, and why.

5. It applies the rules you wrote, not its own. An early-payment discount taken inside your terms is a rule. An agreed freight or rebate deduction with a code you recognize is a rule. Anything that is not a rule you wrote is not applied — it is named.

6. It names the gap instead of absorbing it. Short paid, over paid, or paid with nothing to apply it to. The amount, the invoice, and the reason if the remittance gave one — a damaged pallet, a pricing dispute, a credit they think they have. A difference inside your tolerance is still recorded, not hidden.

7. Nothing posts unless it ties out. The allocation has to equal the payment, to the cent, with every deduction accounted for by a rule or sitting in an exception. A batch has to reconcile to the deposit total before the run is called finished.

8. The clean ones post; the rest wait with the evidence. A clean allocation lands in your ledger, the invoice closes, and the customer's balance is right. An exception goes to a person with the payment, the remittance, the invoices it nearly matched and the difference already worked out — which is the part that used to take the morning.

9. It writes one row per payment. The payment and where it came from, the remittance it used and where that was found, every invoice it touched and for how much, every rule it applied, the unexplained remainder if there was one, the reviewer, and the posting reference.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your customer master and its aliases

The names customers actually pay under, the accounts they pay from, parent and subsidiary relationships, and which of those may never be guessed at.

Your tolerance

The difference you are willing to post without asking, as cash or as a share of the invoice, and whether that changes for a large invoice or a new customer.

Your discount rules

Which terms allow an early-payment discount, how the window is counted, and what happens when a customer takes one they were not entitled to.

Your deduction rules

The codes you accept and what each one means — freight, rebate, promotional allowance, agreed damage — and the ones that always go to a person.

What counts as a dispute

The language and the amounts that stop a payment being an accounting question and make it a conversation, and who owns that conversation.

Your posting rules

Whether an unidentified payment sits unapplied, on account, or in a suspense account you nominate, and how long it may sit there before somebody is told.

Your exception routing

Where each class of exception lands and who owns it — email, Slack, Microsoft Teams, or the queue in your accounting system your team already works out of.

Your systems and your files

Which ledger the allocation is written to, how the bank detail reaches us, where remittance documents are stored, how long they are kept and who can open them.

The words it uses

The wording of the question that goes back to a customer about a deduction, and the versioned prompts behind the reading — yours to read, yours to tune.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every proposed line names the invoice, the amount and the evidence — which remittance, which reference, which rule. You can see why the bot thinks a wire with no detail belongs to four invoices before you agree with it.

Versioned prompts you can tune yourself

The prompts behind reading a remittance are yours to read and yours to tune. A change is a reviewable diff, replayed against payments you have already applied so you can see exactly what it would have done differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Clean, tied-out allocations are automatic. A short pay, an unexplained deduction, a customer it cannot identify or a dispute is a person's decision — that boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per payment and one per allocated line: what it read, what it applied, what it could not explain, who cleared it — plus token usage and cost for that run.

It can be configured to run in any business. The customers and the rules are yours: your tolerance, your discount terms, your deduction codes, your ledger. The receivables wiring on this page is one configuration of it, not the limit of it.

Works with your tools

This runs on top of the ledger and the bank you already use. We're not replacing your accounting system or touching your payment rails.

• QuickBooks Online
• Xero
• NetSuite
• Sage Intacct
• SAP Business One
• A bank feed or BAI2 file
• A lockbox file
• Stripe
• A remittance mailbox
• A customer payment portal
• Email, Slack or Microsoft Teams

Works well for

• Staffing agencies — Clients pay by purchase order and cost center, so one check lands against a dozen weekly invoices.
• Wholesale distributors — Customers deduct for freight, damage and promotions, and the deduction arrives without an explanation.
• Freight carriers and brokers — Shippers pay bundles of loads short and the detail is in a portal nobody has time to open.
• Law firms — Payments arrive against matters and retainers, and applying one to the wrong matter is the error nobody wants.
• Healthcare billing offices — Remittance arrives separately from the deposit, and the adjustments have to be read line by line.

How a rollout works

Nothing posts on day one. A dry run over payments you have already applied comes first, and it is where your own numbers come from.

1. 01Discovery

   The quote call, then a working session. We go through how payments and remittance reach you, your customer master and its aliases, your tolerance, your discount terms and deduction codes, and what access your ledger allows. You get the matching design, the exception classes and a written scope.

2. 02Dry run

   The bot runs over payments your team has already applied. Nothing is written anywhere. It proposes an allocation for each one and we compare it, line by line, against what was actually posted. Every disagreement is either a rule to fix or a miss worth knowing about — and this is where your own numbers come from, on your own cash.

3. 03Assisted mode

   Live. The bot proposes every allocation and a person approves it, with the remittance and the near-misses beside it. The morning spent reconciling becomes a morning spent on the handful that are genuinely unclear. The control doesn't change.

4. 04Optional straight-through posting

   Optional, and only for allocations that tie out to the cent with a remittance that names every invoice. Everything else keeps going to a person, with every hard stop in force and the kill switch. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No match rate, no percentage of cash applied without a person, no “close in a day”. We haven't run this on your cash. The dry run is where those numbers come from, and they'll be yours.
• No customer claims on this page. No names, no case studies, no logos.
• It cannot invent remittance that does not exist. A wire with no reference from a customer who pays randomly and never sends detail is going to be an exception. The bot narrows it to the likely invoices and shows its working; it does not pretend to know.
• It isn't collections, and it isn't credit control. It applies the cash that arrived. Chasing what hasn't arrived, setting limits and deciding who gets put on hold are different jobs with different approvers.
• Fully autonomous application isn't on offer. The design assumes a person owns every exception, and that nothing posts unless it ties out. That's deliberate, and it's why the boundary is written down.

Questions people ask

Can AI apply customer payments to our invoices?

Yes - and the matching is the part everyone underestimates. An AI agent can read the remittance wherever it arrived, work out who paid even when the name on the payment is not the name on the account, and propose an allocation across your open invoices including the awkward shapes: one payment covering many invoices, one invoice settled by two payments, a set that only balances once a credit is included. What it does not do is decide what to do about a difference it cannot explain. That stays a person's decision, every time.

What happens when a payment arrives with no remittance?

It is narrowed, not guessed. The bot looks for the detail in the AR mailbox, in attachments, in a spreadsheet, in a customer portal and in whatever reference survived in the bank description, and it says which source it used. If none of them resolve it, the payment is held with the invoices it nearly matched, the differences already worked out, and how this customer has paid before - or it is parked exactly where you told it to park unapplied cash, with an age on it, so nothing quietly disappears.

How does it handle short payments and deductions?

It names them. A deduction that matches a rule you wrote - an early-payment discount inside your terms, an agreed freight or rebate code you recognize - is applied and recorded as that rule. Anything else is an exception with the amount, the invoice and the reason the remittance gave, if it gave one. A difference small enough to sit inside your tolerance is still written down rather than hidden, because the pattern across a quarter is usually the interesting part.

Will it write off the difference to close the invoice?

No. It issues no credit memo, posts no bad-debt entry and makes no adjustment that would make a balance look tidier than it is. There is no configuration in which the bot decides to absorb a difference - that is a person's call, in your own system, with the reason recorded. An invoice that is genuinely short paid stays short paid until somebody decides otherwise.

Can it cope with one payment covering many invoices?

Yes, that is the normal case rather than the exception, and so is the reverse - one invoice settled by two or three payments over a month. The bot proposes the full allocation, names every invoice and amount, and will not post it unless the total equals the payment to the cent. Where a combination only balances if a credit is included, it says which credit, so you can agree or disagree with the reasoning rather than the result.

Does it get access to our bank account?

No. It reads a feed or a file your bank already produces - the same statement data your accounting system imports - plus a lockbox file or a processor's batch if you have them. It holds no banking credential, initiates no transfer and issues no refund. The only thing it writes is a payment application in your own ledger, scoped to a run id so a batch can be reversed as a unit.

What about a payment from a parent company or a factoring house?

It is identified as such and the relationship has to already exist in your customer master. The bot will tell you that the paying entity is not the account being credited and show you why it thinks they are related - the remittance named your invoices, or that pay-from account has settled this customer before. What it will not do is force a payment onto the closest-sounding account, which is the error that takes months to unpick.

Does it work with NetSuite, QuickBooks Online or Xero?

Yes - by API where the system has one, or as an import your own team runs where it does not, alongside Sage Intacct, SAP Business One and card processors like Stripe. If your ledger is not one of those, the question is only whether it can accept a payment application by API or import and whether we can read your open-invoice list. A dry run needs neither. Naming a system means we can read or write it, not that we are partnered with it.

Is there a record of how each payment was applied?

Yes, and it is built for the person who gets asked why a customer's balance looks wrong. One immutable row per payment records where the payment came from, which remittance was used and where it was found, every invoice touched and for how much, every rule applied with its version, the unexplained remainder if there was one, the model and prompt version, who cleared it and UTC timestamps. The batch reconciles to the deposit total or the run is reported as incomplete.