Matching bank payments to pro formas from messy references, and chasing the rest
Every hour, a Make scenario reads new money in from the bank feed in Xero, has Claude pull the pro forma number out of whatever the client typed as a reference, and marks the job paid or part-paid in the ledger, with a receipt or an alert. Once a day, a second scenario chases the pro formas that are still unpaid.
Where this applies
Any business that asks clients to pay a pro forma or invoice by bank transfer and has to work out who paid what from the bank reference.
- hourly bank-feed checks, no errors
- 788
- routes: matched, mismatched, no reference
- 3
- chase a day at most, logged on the row
- 1
The problem
Clients paying by bank transfer type whatever they like in the reference: the pro forma number with a typo, the event name, their company, or nothing. Matching a line on the bank feed to the right job is a person reading statements, and until they do, the ledger says unpaid and the client may be chased for money they have already sent.
Exact-match rules break on the first creative reference, and a person checking every line does not scale into the busy season. A payment can also be short, so 'found the job' and 'the job is paid' are different answers.
What we built
Only money in
The scenario watches bank transactions in Xero on an hourly schedule, and a filter lets only incoming payments through. Outgoing payments never reach the model.
The model reads the reference, the ledger decides
Claude is given the bank reference and asked for one thing: the pro forma number in it. That number is then looked up in the Google Sheets ledger. The model never marks anything paid; the lookup and the amounts do.
Paid, mismatched or no reference
A router splits the outcomes. A matched payment updates the ledger row and emails the client a receipt. A match that does not add up, such as a part payment, is raised with a person by email instead of being marked paid. A payment with no usable reference goes down a third route: a second search of the ledger, an update where the job is found, and an alert to a person.
A daily chase that remembers
At one o'clock each day a second scenario reads the ledger for pro formas that are still unpaid. One that has not been chased gets a reminder with the pro forma attached, fetched from OneDrive; one already chased gets a follow-up. Each send is written back to the row, so nobody is chased twice in a day, and a skip handler keeps one bad row from stopping the rest.
The outcome
Both scenarios are live. From 19 September to 21 October 2026 the payment watcher ran 788 times without an error and the chaser 33 times with two errors: 821 runs and 1,653 credits in all.
Payments are marked against the right job from the reference, and the ones that do not add up go to a person rather than being marked paid.
Where it stops
It depends on the reference holding something the model can turn into a pro forma number; a payment with nothing usable still needs a person. Part payments are flagged, not reconciled. Nothing here writes back to Xero: the ledger, not the accounting system, is where a job is marked paid. Pausing the chase when a client replies and raising the VAT invoice after the event are separate scenarios that are not described here.
Built with
- Make.com
- Xero
- Anthropic Claude
- Google Sheets
- Microsoft Outlook
- OneDrive
Patterns used
- AI extracts, lookup decides
- Filter before the model
- Part-payment branch
- Chase state on the row
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no