Catalog / Agents & Process Automation / AGENT-023

Order-to-cash agent: cash application, dunning, collections & deduction handling

An agent that matches incoming payments to open receivables, predicts late payment, runs staged dunning and collections, and prepares dispute and deduction cases for finance teams.

Parts needed to run it yourselfAgents & automationDocument readingLanguage modelPrediction & time series

Receivables teams spend much of their day matching bank lines to invoices, reading remittance emails, chasing late payers and sorting out short payments. An order-to-cash agent automates the high-volume core: it clears payments, scores which invoices will be late, sends stage-appropriate reminders in the customer's language, logs promises to pay and assembles dispute evidence. Humans keep key accounts, write-offs and legal steps.

Problem & value

  • Today: Payments arrive as camt.053/MT940 lines with poor references; one transfer may cover several invoices, net off credit notes or short-pay with a discount. Rules in the ERP clear the easy cases; the rest goes to manual work. Dunning is often a monthly batch run with the same letter for every customer, and disputes surface only when someone calls.
  • AI value: more automatic clearing (fewer unapplied cash items), earlier and better-targeted collection contact, shorter days sales outstanding (DSO), less friction with good customers, and faster root-causing of deductions.
  • Evidence: SAP states a 71% reduction in AR matching effort for its Cash Application (vendor claim, not independent) [1]. HighRadius advertises AI agents across cash application and collections, again as vendor claims [2]. Treat all such figures as upper bounds and measure your own baseline.
  • Regulatory pull: the Commission proposed a regulation on combating late payment in commercial transactions (2023/0323(COD)); Parliament adopted its position in 2024; the Council position and final adoption were still pending in the sources reviewed, so check the current status [3].

Variants

  • Cash application & incoming-payment matching (AR): the first sub-step. Bank-file parsing, remittance extraction, one-to-many and partial matching, deduction codes. Product examples: SAP Cash Application, Serrala, HighRadius.
  • Receivables management & dunning with payment-behaviour prediction: the second sub-step. Delay prediction per invoice, prioritised worklists, escalating dunning, promises to pay, instalment plans. Examples: collectAI (DE), Chaser, Upflow (FR). See PRED-021 for the prediction model.
  • Deduction and dispute handling: common in retail and FMCG supply chains (promotions, returns, shortages). The agent gathers proof of delivery and price agreements and routes the case to sales or logistics.
  • SMB / B2C variant: lighter flow inside accounting tools (DATEV, Lexware Office, sevDesk), with polite reminder emails and payment links; B2C collections add consumer-protection limits on tone and fees.
  • Voice channel: outbound reminder calls are covered in CONV-008.

How it works

  1. bank files (camt.053/MT940) + remittance emails/PDFs + ERP open items
  2. parse & extract (remittance lines, references, payer names)
  3. candidate matching (rules
  4. ML ranker
  5. LLM for free-text remittances)
  6. clearing proposal (full / partial / bundled / short pay, deduction code)
  7. auto-post above confidence threshold | review queue below
  8. prediction (P(late), expected pay date)
  9. prioritised collector worklist
  10. dunning engine (policy stage + channel + language, LLM drafts text)
  11. customer replies: promise to pay / dispute / paid-already
  12. classify, log, act
  13. dispute pack (POD, contract price, credit note)
  14. route to owner
  15. escalation: key accounts, legal, write-off proposals
  16. human decision
  • Matching: a deterministic layer (exact reference, amount, tolerance) clears most items; a learned ranker over past clearings handles the rest; an LLM reads unstructured remittance advices and proposes the invoice list.
  • Prediction: gradient-boosted models on payment history, terms, invoice features and seasonality, usually better than an LLM on tabular data.
  • Agent layer: an LLM orchestrates tools (query ledger, read mail, draft message, create task) within the dunning policy.
  • Human-in-the-loop: review of low-confidence matches, all write-offs and credit blocks, key-account contact, legal dunning steps, and any change to payment terms or bank details.

Data preparation

The agent needs bank statements (camt.053, MT940), the open-item ledger, customer master data with payment terms, dunning policy and the history of payments and clearings. In an SMB these sit in the ERP or accounting system (DATEV, SAP, Dynamics), in online banking exports, and in mailboxes where remittance advices arrive as PDF or text. Typical gaps are unclear or free-text payment references, duplicate customer accounts, wrong or missing payment terms, remittance advices only on paper or in portals, and past manual clearings that were never labelled.

Concrete steps: connect ERP and bank exports reliably (PREP-005), clean and merge duplicate customer records (PREP-011), and convert mailbox and PDF remittances to readable text (PREP-007, DOC-014). Harvest labels from existing clearings, because every booked match is a training and test example (PREP-020). Build an evaluation set from a few months of resolved cases (PREP-018) and define deduction and dispute categories (PREP-019). Document the dunning policy as a clear rule text (PREP-016). Restrict access to financial and customer data and pseudonymise test data (PREP-022). Plan roughly a quarter to a third of the effort for this. For a readiness check use GUIDE-003.

Implementation paths

Which path for whom

  • SMB: A. Mature cash-application and dunning modules exist in DATEV, ERP add-ons and EU-hosted finance tools at SMB prices, and the process is standard.
  • Enterprise: B. Large volumes, SAP or Dynamics integration and company-specific deduction logic favour an own pipeline on cloud APIs, where seat-based products get expensive.
  • Developer: B. Matching logic, ERP connectors and prompt-controlled dunning texts are best built on cloud APIs with open workflow tools.
  • ERP-native: SAP Cash Application and SAP Receivables Management for S/4HANA; Microsoft Dynamics 365 Finance collections and payment prediction [1].
  • Specialist AR platforms: HighRadius, Serrala (DE), Billtrust, Esker (FR), Upflow (FR), Chaser, Tesorio, Kolleno. Collections specialists: collectAI (DE), Intrum, Creditreform-linked services. Marked EU: Serrala, Esker, Upflow, collectAI.
  • Check: SAP/DATEV connectors, camt.053 and remittance email handling, dunning-policy configurability, EU data residency, audit trail.
  • Choose A when: you already run SAP or DATEV, volume is thousands of payments/month, and you want proven matching without model ops.

Path B — Build on cloud APIs

  • Document and email extraction: Azure AI Document Intelligence, Google Document AI, AWS Textract, Mistral OCR (EU), or a multimodal frontier model with structured JSON output for remittance PDFs.
  • Reasoning and drafting: frontier LLMs through EU-region endpoints (Azure OpenAI EU, Vertex AI EU, Bedrock Frankfurt, Mistral).
  • Tabular ML: XGBoost/LightGBM for delay prediction and match ranking, trained on your ledger history.
  • Orchestration: n8n, Camunda or a Python agent framework; ERP integration via SAP OData/BAPI, DATEV interfaces, or bank APIs (PSD2/ISO 20022).
  • Choose B when: you need custom dunning logic or an unsupported ERP, and have a developer team.

Path C — Self-host (open source)

  • Models: open-weight LLMs (Mistral, Qwen, Llama families) via vLLM/Ollama for email classification and drafting; Docling or PaddleOCR for remittance PDFs; LightGBM for prediction.
  • Stack: n8n or Camunda, PostgreSQL, a reconciliation library plus your own rule layer; archive per GoBD.
  • Hardware: HW2 is sufficient for mid-sized volumes; no GPU is needed for the tabular models.
  • Effort: needs a data engineer and finance product owner; no open-source product matches mature AR suites.

Path D — Custom training

Worth it for large volumes with idiosyncratic remittance formats or portfolios with long payment histories (hundreds of thousands of cleared items). Train a pairwise match ranker and a payment-delay model on your own history; reviewer corrections are the natural labels. Fine-tuning an LLM is rarely necessary.

State of the art (2026)

  • Hybrid matching (rules + ML + LLM for unstructured remittances) is standard in vendor products; vendors market agents that read remittance emails and also draft collection messages [1][2].
  • Agentic collections: LLM agents conduct multi-step contact (reminder, reply parsing, promise to pay, follow-up) within policy guardrails; autonomy is typically limited to low-value, low-risk accounts.
  • Prediction remains tabular ML; gains come from clean payment history, not larger models.
  • Limits and failure modes: wrong clearing of a bundled payment (hard to unwind), hallucinated invoice numbers in drafts, tone problems with sensitive customers, disputes misread as late payment, duplicate or conflicting reminders sent by sales and finance, and prompt injection through inbound email content. Cross-check amounts and invoice IDs against the ledger, never let the LLM write a posting directly, and suppress dunning while a dispute is open.

Shared resources & combinations

Effort, cost & KPIs

  • Path A: weeks to 3 months including ERP connector and rule set; priced per user, per transaction or by revenue band.
  • Path B: 3-6 months; LLM cost per document is small compared with analyst time, the main cost is integration and testing.
  • Path C: 4-8 months plus continuing operation.
  • KPIs: auto-match rate (by count and value), unapplied cash ageing, DSO and best possible DSO, overdue share, collector productivity, promise-to-pay kept rate, dispute cycle time, wrong-clearing rate, customer complaints about dunning.

People & change

Involve management for risk appetite (tone of dunning, thresholds), the head of finance or accounts receivable as process owner, and the clerks who clear payments and chase invoices from the start, since their corrections create the labels. IT connects ERP and bank interfaces; the data owner of customer master data approves cleansing. The data protection officer checks personal data of sole traders and contact persons, the AVV (Art. 28 GDPR) with providers, and whether a DPIA is needed; customers are affected by the dunning messages, so tone and escalation rules need sign-off.

Works council: depends. If the tool records or ranks individual clerks' processing times or error rates, §87(1) no. 6 BetrVG applies because objective suitability for monitoring suffices; otherwise inform in good time under §90(1) no. 3. Public bodies involve the Personalrat.

Start with a pilot on cash application for one bank account or one customer group, running in suggestion mode, then widen. Keep a human approval for dunning of key accounts, disputes and any write-off. Typical concerns are job loss and damaged customer relations; show that clerks move to exceptions and negotiation. Support AI literacy (AI Act Art. 4 requires measures to support it). See GUIDE-009, GUIDE-008 and GUIDE-005.

Risks, regulation & compliance

  • EU AI Act: typically minimal risk; B2B receivables handling is not in Annex III. If the agent scores natural persons to decide access to credit or essential services (e.g. consumer creditworthiness), it can fall into the high-risk category (Annex III 5(b)); prediction for collections prioritisation alone is generally not creditworthiness evaluation, but test this per case. AI literacy duty (Art. 4) applies. Customer-facing chat or voice needs AI disclosure (Art. 50) [4].
  • GDPR: sole traders and consumer debtors are personal data; document the legal basis (contract / legitimate interest), run a DPIA for consumer scoring, and avoid decisions based solely on automated processing with legal effect (Art. 22) such as automatic credit blocks on consumers [5].
  • Sector and national rules: dunning fees and debt-collection conduct rules (e.g. German BGB §286 default rules, registration of collection agencies under the RDG); consumer-protection limits on tone and frequency; GoBD for posting traceability; PSD2/SEPA data handling.
  • Mitigations: confidence thresholds, auto-posting limits, four-eyes principle for write-offs, dispute suppression, template-bound messages with approved wording, audit log of every AI proposal vs. final action.

Getting started

  1. Measure your baseline: auto-match rate, unapplied cash, DSO, share of items needing manual work and why.
  2. Export 6-12 months of bank lines, open items and clearings; label the exception categories.
  3. Pilot cash application first (lowest risk, highest effort saving) in proposal-only mode; compare against clerks' decisions.
  4. Add delay prediction and a ranked worklist, then enable AI-drafted dunning for low-risk customer segments under approval.
  5. Define the dunning policy, escalation owners and dispute suppression before any autonomous sending.

Sources

  1. SAP — SAP Cash Application — https://www.sap.com/products/financial-management/cash-application.html
  2. HighRadius — AI-powered Accounts Receivable software — https://www.highradius.com/product/accounts-receivable-software/
  3. European Commission — Late Payment Directive (SME strategy page) — https://single-market-economy.ec.europa.eu/smes/sme-strategy/late-payment-directive_en
  4. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  5. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
  6. SAP Insider / Mastering SAP — SAP Cash Application leverages machine learning — https://masteringsap.com/expert-insights/machine-learning-enables-sap-cash-application-automation/
  7. Ibec — Late Payments Directive faces further delays — https://www.ibec.ie/sfa/news-insights-and-events/insights/2025/02/11/late-payments-directive-faces-further-delays