AI Agents for SAP ECC6
Accounts Payable
An RFC enabled BAPI does not commit. On ECC6 that is not a limitation to work around, it is the control an AP agent should be built on.
- An RFC enabled BAPI does not auto commit, so a document an agent creates is parked and waits for release through SAP workflow. The control is structural rather than a setting somebody can turn off.
- Read RBKP and RSEG, not just the accounting document. Line level links back to the purchase order and the goods receipt are where a payables difference is explained.
- BSIK and BSAK are separate tables. An ageing built only on open items understates history and cannot explain a movement.
- Aged goods receipt and invoice receipt items are the clearest first use case. In a worked population of 41, twenty five had a mechanical answer and five were a purchasing conversation.
- The duplicate that gets paid is the one where the reference changed. The goods receipt is the test that catches it, because one receipt cannot support two invoices.
AI agents for SAP ECC6 accounts payable read through RFC enabled BAPIs and the invoice verification tables, prepare the work, and create a parked document for a person to release through SAP workflow. Because an RFC enabled BAPI does not commit by itself, the approval point is structural rather than configured. ChatFin uses that parked document as the control, so no new approval mechanism has to be built or audited.
The work worth giving an agent on ECC6 payables is narrow and specific. Aged goods receipt and invoice receipt clearing, blocked invoice analysis by reason rather than by invoice, duplicate detection that tests the goods receipt rather than the reference, and accruals priced from the purchase order. All four are retrieval across tables a person can open, and all four are what gets signed on judgement when the close runs short.
The parked document is the control, not a workaround
An RFC enabled BAPI does not commit. A document an agent creates through one exists in SAP, carries a document number and an audit trail, and is not in the ledger until somebody releases it. On ECC6 that is the whole safety argument for putting an agent in payables, and it needs no new approval mechanism.
ChatFin creates parked documents and stops. Release runs through your existing SAP workflow, which is why there is one approval system rather than two.
Where invoice verification differences actually surface
Logistics invoice verification is where a payables problem becomes visible, and the tables behind MIRO are where an agent should be reading rather than at account level.
| Object | What it holds | Why it matters |
|---|---|---|
| RBKP | Invoice document header from invoice verification | Vendor, date, gross, and the reference the duplicate check runs on |
| RSEG | Invoice document line items | The line level link back to the purchase order and the goods receipt |
| BKPF and BSEG | The accounting document and its lines | What actually reached the ledger, which is not always what MIRO shows |
| BSIK and BSAK | Vendor open and cleared items | Two tables, which matters for any ageing or payment proposal |
| GR and IR clearing | Cleared through MR11 | The usual home of aged items nobody owns |
The split between BSIK and BSAK trips naive analysis constantly. An item that cleared yesterday is not in the open table today, so an ageing built only on BSIK understates history and cannot explain a movement.
ChatFin reads open and cleared together and states which it used, because a payables figure drawn from one table alone is a different question than the one usually being asked.
Tolerance keys, and the one nobody revisits
ECC6 tolerance configuration decides what blocks and what flows. It is usually set once at go live and then treated as physics.
Report blocks by reason and by vendor, monthly
The individual block is an AP task. The pattern is a purchasing or master data task, and only one of those removes the work permanently.
Test tolerances against current volume once a year
An absolute tolerance should be restated in the same review that restates budgets.
Separate blocks that will clear themselves from blocks that will not
Waiting on a goods receipt clears on its own. A price disagreement does not, and mixing them makes the queue look worse than it is.
A worked GR and IR population, 41 aged items
The clearing account carries 41 open items over 90 days, 386,000 gross. Nobody works them because each takes twenty minutes. Read across RBKP, RSEG and the purchase order history, they are five patterns.
| Pattern | Items | Gross | Proposal |
|---|---|---|---|
| Goods received, invoice never arrived | 14 | 162,000 | Vendor follow up with the PO, receipt date and contact |
| Invoice posted against the wrong PO line | 9 | 88,000 | The matching line, with quantity and price that reconcile |
| Quantity difference inside tolerance | 11 | 31,000 | Clear through MR11, with the tolerance rule named |
| Price difference outside tolerance | 5 | 94,000 | Escalate to purchasing. A commercial question, not a clearing one |
| Duplicate receipt | 2 | 11,000 | Both documents named, with the reversal that was never posted |
Twenty five of the 41 have a mechanical answer. Five are a purchasing conversation. The value is not cleverness, it is that all 41 got looked at.
The duplicate the standard check misses
The ECC6 duplicate check runs on the reference field. The invoice that gets paid twice is the one where the reference changed, which is exactly the chased document a supplier resent with a new number on payment run day.
ChatFin runs the goods receipt test alongside the reference test and parks anything that fails either. A parked document costs a conversation. A paid duplicate costs the money and the recovery.
The payment proposal, checked before it goes out
F110 builds the proposal from what is open and due. Everything that makes a payment run wrong happened before that, and an agent is useful precisely in the window between the proposal and the release.
Re test duplicates against the proposal, not the ledger
The proposal is the last moment a duplicate can be stopped cheaply. Testing at entry misses anything entered since.
Check unapplied credits against every payee
Paying an invoice in full while holding an unapplied credit for the same vendor is the most common avoidable overpayment.
Confirm bank detail changes since the last run
A vendor bank change between runs is the pattern behind most payment fraud. It should be surfaced as a list, every run, whether or not anyone suspects anything.
Report what is being paid outside terms
Early payment with no discount taken is a cash cost with no benefit, and it is invisible in a proposal sorted by due date.
Report blocked value that should have been in the run
The proposal shows what is going out. The more useful number is what is not, and why.
ChatFin reads the proposal before release and returns duplicates, unapplied credits, changed bank details and blocked value as four separate lists. It releases nothing.
Where this underperforms on ECC6
Three, and all three are worth testing before a pilot.
ChatFin feeds SAP workflow rather than replacing it. Where the standard transaction already handles a case cleanly there is no reason to add an agent.
Deeper in SAP ECC6 payables
Three use cases sit under this hub, in build and shown rather than linked.
Worked on this page
Vendor follow up for missing invoices · AP inbox automation · Invoice intake and document extraction
Covered as sections here
2 way and 3 way matching · Duplicate detection · Payment preparation and validation · Approval routing · GL coding · Accrual identification from open POs
Questions SAP payables teams ask first
Can an AI agent post an invoice directly in SAP ECC6?
It should not, and on ECC6 the interface makes that easy to enforce. RFC enabled BAPIs do not auto commit, so a document created through one is parked rather than posted and waits for release through SAP workflow. ChatFin is built on that behaviour. The agent prepares the document with the matching evidence attached, and a named person releases it under the release strategy that already exists.
What should a SAP payables team automate first?
Aged goods receipt and invoice receipt clearing. It is pure retrieval across RBKP, RSEG and the purchase order history, the proposals are checkable in seconds, and everyone already knows the population is not being worked. ChatFin groups the items by pattern, proposes clearing where a tolerance rule already covers it and names that rule, and escalates price differences because those are a purchasing conversation.
How do you catch a duplicate invoice in SAP when the reference changed?
Test against the goods receipt. The standard ECC6 duplicate check runs on the reference field, which is exactly what changes when a supplier resends a chased document under a new number, usually in the days around the F110 payment run. One goods receipt cannot support two invoices for the same goods, so ChatFin runs that test alongside the reference test and parks anything failing either.
It parks the document. Your team releases it.
ChatFin reads ECC6 through governed RFC access, groups aged clearing items and blocked invoices by cause, and prepares invoices, clearing proposals and accruals as parked documents with the evidence attached.
Release runs through the SAP workflow your team already uses. There is no second approval system and no second source of truth.
Bring your aged goods receipt and invoice receipt population. 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 your GR and IR ageing.
We will read the same population through ChatFin, group it by pattern, and show the purchase order history behind every proposed clearing.