The same picture every morning in many accounting teams: the bank statement arrives, someone opens the list of open items next to it and matches payment after payment by hand. With fifty transactions a day this is tedious. With five hundred it is a full-time job. Most of this work can be automated cleanly with n8n. The remainder, the unclear cases, gets much smaller with Claude. Here is the setup we run in practice.
How the bank statement gets into the system
Before anything can be matched, the transactions have to be machine-readable. In practice we see four routes:
- Bank API: Some banks and most fintech accounts offer a REST interface. n8n fetches the transactions via HTTP request, usually several times a day.
- EBICS or FinTS: The standard route for business accounts in Germany. A small client collects the statements and drops them as files, n8n takes over from there.
- CAMT.053 files: The XML format for end-of-day statements. It has structured fields for amount, counterparty, remittance information and end-to-end reference. For matching, it is the best source.
- CSV via SFTP: Often the stopgap when the bank offers nothing else or a payment provider sits in between. It works, but needs maintenance, because columns change without notice.
Whichever route: the first step in the workflow normalises every transaction into one common format. Amount, currency, booking date, payer name and IBAN, remittance text, bank reference. Everything downstream works only with this format.
Deterministic matching first
Most payments can be matched without any AI. n8n fetches the open items from the ERP: from SAP via OData or RFC, from DATEV via its data services, from smaller systems often straight from the database or via REST. Then the workflow checks in a fixed order:
- Is there an invoice number in the remittance text and does the amount match exactly? Match.
- Is there a customer number in the remittance text and exactly one open item with this amount? Match.
- Is the payer's IBAN linked to a customer and does the amount fit exactly one invoice? Match.
- Does the amount equal the sum of several open items of the same customer? Bulk payment, match with a note.
These rules are cheap, fast and easy to explain. Anyone who starts with a language model at this stage pays for something a few lines of code do better.
Unclear cases: Claude reads the remittance text
What remains is the interesting part. Remittance texts like "inv. from 12 Mar Mueller partial", "March invoices less discount" or simply a project name that only one clerk recognises. Here n8n hands the transaction, together with the open items of the likely customer, to Claude. The request is narrow: which item fits, why, and how confident is it.
The answer has to come back structured, otherwise the workflow cannot process it:
{
"match": "INV-2024-0471",
"confidence": 0.82,
"reason": "Amount equals invoice less 2% early payment discount, customer name in remittance text",
"flags": ["discount"]
}
What matters is what Claude does not do here: it books nothing. It proposes. The confidence is a self-assessment, not a guarantee, and we use it only to sort proposals in the approval queue.
Human approval
Every proposal from the fuzzy matching lands in an approval list. That can be a simple table, a form in n8n, or a message in Teams or Slack with two buttons. The clerk sees the payment, the proposed item and the reasoning, and confirms or corrects with one click.
A threshold keeps the list short: proposals with high confidence and no flags can pass automatically after an introduction phase, everything else waits for approval. Where that threshold sits is a decision for accounting, not for IT. We recommend approving everything in the first weeks and watching the hit rate before lowering the threshold.
Booking, audit trail and idempotency
After approval, n8n writes the incoming payment to the ERP and clears the open item. Two things have to be right.
Audit trail: For every booking we store where the payment came from, which rule or proposal applied, who approved it and when. For AI proposals, the reasoning is part of the record. This is not optional, auditors ask for exactly this.
Idempotency: Bank statements arrive twice. The bank re-delivers the daily statement, an SFTP job runs twice, someone triggers the workflow by hand. Every transaction therefore gets a unique key built from bank reference, date and amount, and the workflow checks before processing whether that key is already known. Without this check you will eventually book a payment twice, and you will notice during the dunning run.
What happens with the rest
Even with Claude, a remainder cannot be matched cleanly:
- Partial payments: The amount is smaller than the invoice. The workflow books the payment against the item and leaves the remainder open, with a note for dunning.
- Overpayments and bulk payments without a breakdown: Proposal to the approval queue, with the most likely split.
- Unknown payers: No IBAN in the master data, no name in the remittance text, no matching amount. These payments go to a clearing account and onto a separate list that someone works through daily.
The point is not that the list becomes empty. The point is that it becomes short and only contains the cases where a human really needs to think.
Takeaway
Matching incoming payments is mostly rules and partly interpretation. n8n handles the rules, Claude handles the interpretation, and approval stays with your team. Built properly, this runs stably, traceably and without double bookings.
If you want to know what this looks like with your bank and your ERP, book a free 30-minute intro call at /en#kontakt.