Every month the same ritual: SAP generates the outbound payment file, the file goes up to the VAN (the value-added network that carries bank files in Brazil), the bank processes it, the return file comes down, someone imports it — and then begins the part nobody puts in the schedule. A payment that was never confirmed. An item cleared for a different amount. A return file carrying a code nobody knows by heart. A statement that will not reconcile with the ledger over a few cents, and eats the whole afternoon.

Bank communication is one of the oldest integrations in any ERP and, curiously, one of the least observed. It runs for years with little attention — until the day a file does not arrive, and nobody notices before the supplier calls.

What breaks in bank integration

After several years running this flow in SAP environments, the problems repeat with an almost tedious consistency.

• The file that never arrived. The outbound file left SAP and stopped halfway — expired credentials, an out-of-date certificate, a full directory, a closed banking window. The system says it generated the file; nobody says it delivered it.
• The return file that was never imported. The bank processed it, the file is there, and the import failed silently. The items stay open in the ERP and cleared at the bank.
• Rejection without translation. The return file carries an occurrence code and a short description. Anyone who does not live with that layout every day loses half an hour per rejection.
• Amount discrepancies. Interest, discounts, fees and allowances make the amount paid differ from the item. Part of that is rule, part is exception — and separating the two is the manual work.
• Duplication on reprocessing. Someone imports the same return file twice because it was not clear whether the first attempt worked.
• A statement that will not reconcile. Automatic reconciliation catches most of it; the leftovers go to a spreadsheet, and the spreadsheet becomes the real process.

Note that the first three are observability, and the last three are classification. They are different problems and the order of solving them matters: automating the reconciliation of a flow that loses files in silence is building on sand.

Observe first, automate afterwards

The layer that almost never exists is the cheapest to build: knowing, without asking anyone, whether the day’s cycle actually happened.

Generate. The outbound file was created, with how many records and what total value. This is already what the ERP records — it simply tends not to be compared with anything afterwards.

Deliver. The VAN or the bank’s channel confirmed receipt of that specific file. Without that acknowledgement, “we sent it” is only an assumption.

Return. The day’s file arrived, at the expected time, intact and with a coherent sequence. A return file that never arrives matters as much as one with errors — and it is the easiest to miss.

Reconcile. The clearing was applied; whatever did not match is identified, with a reason, and not sitting in an anonymous queue.

With those four points instrumented and an alert that has an owner, most of the incidents that become a 5 pm crisis today become a 9 am notification. This is observability applied to finance — before any conversation about AI.

Where AI genuinely comes in

With the flow observable, four uses pay for themselves.

Translating the return file. Each bank has its own set of occurrence codes and reasons, and the official description is terse. An assistant with the layout and the history returns what happened in human language, what usually causes it and what the action was on previous occasions. It is the difference between escalating and resolving.

Reconciling the leftovers. Exact reconciliation handles the majority. The rest is similarity: a close amount, a shifted date, a memo line with the payer’s name spelled differently, a grouped payment that settled three items. Matching that is pattern recognition over free text — territory where the model is good and the exact rule is poor. The AI suggests the match, with a justification; the person confirms.

Explaining the difference. When the amount paid differs from the item, breaking it down into interest, penalty, discount, fee and allowance — and saying which part is expected under the contract terms and which is not.

Flagging what departed from the pattern. A daily volume outside the curve, a bank that delayed its return file, a rejection rate rising with one specific agreement, a payment at an unusual hour. It is not a block: it is a short list for someone to look at before it becomes a problem.

The design: n8n orchestrates, SAP remains the owner

We use n8n on the client’s own infrastructure to orchestrate the cycle: track the outbound file, confirm delivery, fetch the return file within the expected window, check integrity and sequence, trigger the import into SAP and raise an alert when one of the gates does not close. SAP remains where the financial document lives.

Running it in-house is, here, less a preference than a requirement: banking credentials and payment files should not travel through a third-party cloud without need. And the secret belongs in the infrastructure’s vault, not in the flow — a rule that holds for any automation, and all the more for this one.

The AI portion operates on the return file and the reconciliation: item data, amounts and history. It is worth deciding explicitly what may be sent to an external model and what must not leave — an architecture decision, taken once and recorded, not improvised by whoever builds the flow.

How we start

1. Map the real cycle. How many agreements, how many banks, which layouts, which time windows, who operates each end. There is almost always an agreement nobody knew still existed.
2. Instrument the four gates. That alone eliminates the “we found out too late” category, which is the most expensive one.
3. Measure the reconciliation leftovers. How many items are left over per day and how much time they cost. That is the baseline for the gain.
4. Run the AI in shadow. Suggesting matches and translating rejections without entering the flow, so you can measure real accuracy before promising anything.
5. Open up in bands. First the cases with consistent accuracy; the rest stays manual until it earns its place.

What remains afterwards

The visible gain is the reconciliation afternoon that shrinks. What lasts is three things.

The cycle stops being invisible. Someone knows every day whether the file went out, arrived and came back — without having to ask.

Layout knowledge becomes a lookup. That accumulated know-how about occurrence codes stops depending on who happens to be at the desk.

The difference has a recorded explanation. Every item reconciled outside an exact match keeps the reason and who confirmed it — material ready for an audit and for the conversation with the bank.

The honest limit: none of this replaces a clear commercial agreement with the bank or correct master data for the agreement and the account. Automation on top of wrong configuration delivers errors faster. And, as always, instrumentation tends to be what reveals how much of the flow had already been failing in silence.

If in your case the issue is less the bank and more the volume of postings, the same reasoning applies to the inbound side: see classifying incoming invoices in SAP with AI. And for the foundation that holds this kind of flow together, the discipline of data and integration is what separates automation that lasts from a script nobody maintains.