AI Agents for SAP ECC6
Receivables
Most wrong AR numbers on ECC6 come from reading one of two tables. An item that cleared yesterday is no longer in the one people query.
- BSID holds open customer items and BSAD holds cleared. An ageing built from BSID alone cannot explain a movement, because anything that cleared has left the table.
- Special general ledger items such as down payments are not ordinary receivables. Including them inflates the ageing and understates cash already held.
- Measure the FEBAN residue, not the auto match rate. Every tool clears the easy receipts. What matters is how much is still unmatched on Friday.
- In a worked residue of 46 receipts, 32 were mechanical. The nine caused by a missing customer reference recur every month until billing captures it.
- ChatFin rebuilds the open position immediately before a dunning proposal and returns the suppression list with a reason for each. It sends and clears nothing.
AI agents for SAP ECC6 receivables read the open and cleared customer tables together, work the electronic bank statement residue sitting in post processing, propose clearing with every line traced to an open item, and check the ledger before a dunning proposal goes out. ChatFin reads through governed RFC access and clears nothing itself, because clearing changes customer standing and credit exposure.
The reason this is worth automating on ECC6 is the shape of the residue. Statements import and rules clear the easy receipts. What remains is a payer name that matches nothing in the master, a single receipt against sixty one invoices with no remittance, and short payments that are settlement discounts rather than disputes. That is a search problem with a checkable answer, and it is what sits in FEBAN on a Friday.
Reading the open side without lying about it
Receivables on ECC6 splits across two tables and most wrong AR numbers come from reading one of them. BSID holds open customer items, BSAD holds cleared. An item cleared yesterday left BSID, so an ageing built from BSID alone cannot explain last month.
| Object | What it holds | Where it misleads |
|---|---|---|
| BSID | Open customer line items | A shrinking table. Fine for today, useless for history |
| BSAD | Cleared customer line items | Where a payment went. Needed for any movement analysis |
| BKPF and BSEG | The accounting documents behind both | The authority when the two disagree |
| Special GL indicators | Down payments, security deposits, bills of exchange | Frequently swept into an ageing where they do not belong |
| FEBAN | Electronic bank statement post processing | Where unmatched receipts sit, often for weeks |
Special general ledger items are the quiet one. A customer down payment carries a special indicator and is not a receivable in the ordinary sense. Including it inflates the ageing and understates cash already held.
ChatFin reads open and cleared together, separates special general ledger items, and states what the figure includes. An AR total with no stated basis is a different number to whoever reads it next.
The electronic bank statement, and what lands in FEBAN
The statement imports, rules run, and whatever does not match sits in post processing. That residue is the actual work, and it is where an agent earns its place.
Match on what the customer sent, then on amount
Reference first, combination second, amount last. Amount first is how a payment gets applied to the wrong invoice of the same value.
Constrain combinations by the total
Sixty one open items has too many subsets to test blindly. Start from exact matches and work outward.
Propose the clearing, do not post it
Clearing affects customer standing and credit exposure, so a person releases it.
A worked FEBAN residue, 46 unmatched receipts
A month of statements leaves 46 receipts unmatched, 611,000. Sorted by value that is 46 investigations. Grouped by cause it is five.
| Cause | Receipts | Value | Where it goes |
|---|---|---|---|
| Payer name differs from the customer master | 14 | 208,000 | Resolvable from bank detail history, then a master data fix |
| One receipt against many invoices, no remittance | 11 | 243,000 | Combination match constrained by the total, proposed for release |
| Customer reference not captured on the invoice | 9 | 96,000 | Matchable this month, but the fix is in billing setup |
| Short by a settlement discount taken in terms | 7 | 41,000 | Allowable, clear on the rule and report the pattern |
| Genuine deduction with a claim reference | 5 | 23,000 | Commercial. Not an AR decision at all |
Thirty two of the 46 are mechanical. The nine in the third row are the interesting ones, because they will recur every month until the invoice carries the customer's own reference. That is a billing configuration change, not an AR task.
The remittance that arrives as a picture of a spreadsheet
Remittance advice is the least standardised document in finance. It arrives as a PDF, a spreadsheet, the body of an email, a scanned print, or not at all, and each customer sends a different one every time.
| Form it arrives in | What breaks | What an agent should do |
|---|---|---|
| Structured file, agreed layout | Nothing, this is the easy case | Parse and match. It should be near total |
| PDF table | Column drift between sends | Read on header names, not on position |
| Email body text | No delimiters at all | Extract reference and amount pairs, and report confidence per pair |
| Scanned print | Character errors in references | Normalise, then match on the amount total as a cross check |
| Nothing sent | The whole difficulty | Combination match constrained by the receipt total, and say so |
The rule that matters across all five is to report a confidence per line rather than per document. A remittance is usually right about fifty eight lines and ambiguous about three, and holding all sixty one because of the three is the wrong outcome.
ChatFin applies what it can support and leaves the rest unapplied with the reason stated. It does not force a match to clear a document.
Dunning that reads the ledger before it sends
ECC6 dunning runs on levels and dates. It does not know that a payment landed this morning, that a credit is sitting unapplied, or that the invoice is in dispute.
ChatFin rebuilds the open position immediately before a dunning proposal goes out and returns the suppression list with the reason for each. It sends nothing.
Credit exposure that is current rather than monthly
Credit limits are checked at order entry against a figure that is often days old. The exposure that matters includes what has not been invoiced yet.
| Component | In the standard check | Why it matters |
|---|---|---|
| Open invoices | Yes | The obvious part |
| Deliveries not yet invoiced | Sometimes | Goods already gone, no receivable recorded |
| Orders not yet delivered | Sometimes | Committed but reversible, a different risk |
| Unapplied cash on account | Rarely | Reduces real exposure and is often ignored |
| Disputed items | No | Inflates exposure and blocks orders that should ship |
An agent can assemble the full picture on demand rather than on a schedule, which turns a credit block from an argument into a checkable position.
Where this underperforms on ECC6
Three, all upstream.
ChatFin reports the match rate ceiling your invoice references create before it reports a match rate. A high rate on a narrow population is not the same thing as a solved process.
Deeper in SAP ECC6 receivables
Three use cases sit under this hub, in build and shown rather than linked.
Worked on this page
AR inbox automation · Open AR analysis · Bank payment to open invoice matching
Covered as sections here
Cash application · Remittance processing · Credit memo handling · Bulk payment matching · Collections support · Chargebacks · Dunning
Questions SAP receivables teams ask first
Why does an SAP AR ageing not explain last month's movement?
Because it was probably built from BSID alone. BSID holds open customer line items and BSAD holds cleared ones, so anything settled has left the table you queried. Any movement analysis needs both, and special general ledger items such as down payments need separating out because they are not ordinary receivables. ChatFin reads open and cleared together and states what the figure includes.
What actually sits in FEBAN and why does it stay there?
Receipts the matching rules could not resolve. In a worked month of 46 unmatched receipts worth 611,000, the causes were a payer name differing from the customer master, one receipt against many invoices with no remittance, customer references never captured on the invoice, settlement discounts taken within terms, and genuine deductions. Thirty two were mechanical. ChatFin groups them by cause and proposes clearing rather than posting it.
How do you stop dunning going to the wrong customers?
Rebuild the open position at send time rather than when the run was prepared, and suppress anything covered by an unapplied credit or sitting in dispute. Standard dunning runs on levels and dates and does not know a payment landed this morning. ChatFin returns the suppression list with a reason for each entry, and escalates on observed payment behaviour rather than on level alone.
The Friday residue becomes a checked proposal.
ChatFin reads BSID and BSAD together, works the FEBAN residue by cause rather than by value, and proposes clearing with every line traced to a specific open item and the matching field named.
It rebuilds the open position before any dunning proposal and assembles live credit exposure including deliveries not yet invoiced and cash on account. It clears and sends nothing.
Bring one month of unmatched receipts. The comparison takes an hour.
Book a demoAll images are served from the Pexels content network. No third party product screenshots, vendor logos or licensed media are used on this page.
Bring one month of FEBAN residue.
We will run the same receipts through ChatFin, group them by cause, and tell you the match rate ceiling your invoice references create.