FI-CA Payment Clarification Agent in Joule Studio: Design

In 30 seconds

What it is An agent that proposes payment assignments, never posts, and is measured on overrides.

You use it when You are designing or reviewing an AI agent that works on FI-CA clarification cases or any payment-assignment exception queue.

Next in this section n8n Workflows in Joule Studio: When a Workflow Beats an AI Agent →

The agent reads and proposes. A clerk approves and posts, and the log keeps every step. Judge it by how often clerks override it.

Part 20 of 26 in SAP Business AI, Explained.

Every utility, telecom and public-sector finance team has a queue of incoming payments that won’t match to any account. On SAP contract accounting (Contract Accounts Receivable and Payable, FI-CA) projects it’s often the first agent idea on the table, because the work is repetitive and leans on evidence. The agent reads each unclear payment, gathers the evidence and suggests which customer account it belongs to, and a clerk approves and posts it. Here’s how I’d design it so it saves time without ever moving money on its own.

How the design fits together

In SAP contract accounting (FI-CA), payments that can’t be posted to a contract account end up in a clarification worklist.
The agent gets two tools, one to read a case and one to record a proposal, and deliberately none that posts. Approval runs in a workflow, every step is logged, and success is measured by proposal accuracy and how often clerks override it.

Maker, checker and the signing stamp

You’ll know the four-eyes principle. A junior analyst prepares the matching and writes down why, a senior clerk checks the evidence and signs, and the junior never gets the signing stamp. Our agent is the junior analyst. It’s fast and tireless, but it doesn’t hold the stamp, and that’s deliberate.

The life of one clarification case

A case enters the worklist. SAP parks the payment on a clarification account, a holding account for money that hasn’t been assigned to a customer yet.
The agent reads the case. A read-only get_case tool fetches the payment, the note to payee and candidate open items.
The agent proposes, or declines. With propose_assignment it records a proposed contract account and items with its reasons. If the evidence is weak, it records “needs human review” instead.
A clerk approves in a workflow, accepting, editing or rejecting the proposal, and posts the clarification in the standard SAP app.
Everything is logged. Inputs, proposal, reasons, decision and the final posting reference are stored together.

One word of caution on terms. In SAP clarification documentation, “agent” often means the human processor a case is reserved for. Here, “agent” means the AI agent, and I call the person a clerk.

A morning in Omar’s clarification queue

NextSAP Utilities, the fictional Dubai utility used across this site’s SAP content, runs billing, payments, dunning and deposits for electricity, water, gas and district cooling for about 5 million customers on SAP FI-CA. None of these people or numbers are real, though the queue will look familiar. Every night the bank statement from house bank NXENB is loaded as a payment lot, a batch of incoming bank payments posted together. Most payments match on their own, but customers paying by bank transfer often leave the reference missing or mistyped, and what the lot can’t assign lands on clarification account 1190100. About 140 unclear incoming payments arrive each working day, often AED 2.3 million overnight, so about 3,000 a month worth about AED 50 million. The shared-services team in India handles each one in roughly 9 minutes, about 450 hours a month.

This is agent 4 in the register: autonomous, custom-built in Joule Studio, autonomy L2 “Propose”, medium risk. Omar, the finance controller, owns it, and Arnav, the FI-CA consultant, designed its two tools. Layla, the Chief Financial Officer (CFO), agreed one rule up front, which is that the agent never posts.

A typical morning case:

A transfer of 3,275.50 UAE dirhams (AED) arrives with the note “INV 4471 4472 Marina Bay”. The payment lot can’t assign it to a single item, so it lands in the clarification worklist.
The agent finds Marina Bay Café LLC, a commercial customer on 30-day terms that pays by bank transfer (payment method U). It has two open bills ending 4471 and 4472, AED 1,840.25 for electricity and AED 1,435.25 for water, which add up to exactly AED 3,275.50.
It proposes that contract account and both items, citing the matching total, the reference digits and the name. Its confidence band is high.
A clerk sees the proposal next to the evidence, accepts it in 40 seconds and posts in the standard clarification app. Until then, both bills still look unpaid, and left long enough they would move into dunning, the automatic reminder letters, for money the café has already sent.

Al Noor Property Management is the trickier regular. It pays for many premises (each building or unit NextSAP supplies) in one transfer, against a collective bill account that gathers their bills into one. When the remittance file lists the premises, the agent proposes the split item by item and shows that the parts add up to the payment. When it doesn’t, the agent declines.

The harder case is AED 10,000 with no reference, from a payer name that matches no customer. The agent declines to propose and says why. Omar counts that as a correct answer, and so would I.

For a four-week pilot, Omar is aiming for proposal accuracy above 90% on cases where the agent does propose, an override rate below 10%, and handling time down from 9 to 4 minutes on proposed cases. If the agent proposed on every case, that would cut about 450 hours a month to about 200, freeing roughly 250 hours. It won’t propose on every case, so the real saving will be lower. These are pilot targets to measure, not results.

To see these controls working, my payment clarification lab simulates the pattern locally with synthetic cases, including tests that reject a forged account and an attempted post.

Should you build an agent, or use what SAP gives you?

Start with what SAP already provides, and add the agent only where it earns its place.

Option	What it is	When I would use it
Clearing rules and the system clarification proposal	Standard SAP. When a clerk opens a case, the system suggests a proposal and can show recent payments and due items	Always, as the baseline the agent must beat
SAP Cash Application, add-on for contract accounting	An SAP add-on that supports clarification postprocessing. Needs a separate licence	When volumes are high and you prefer a standard product
Custom agent in Joule Studio	Reads messy notes and documents, explains its reasoning, proposes	When notes, emails or remittance files carry the evidence rules cannot read
Clerk only	Manual clarification in the worklist	Rare, high-value or disputed cases

What the agent is never allowed to do

The agent reads a case and its evidence, proposes an assignment or declines with reasons, and leaves a full audit trail. It doesn’t post, clear, transfer or create repayment requests. It doesn’t touch master data or clearing rules. Disputed and high-value cases always go to a clerk.

Explain it to your CFO

The system prepares unmatched customer payments with the evidence attached, so our team decides faster.
It can’t move money. A named person approves and posts every case.
We track how often our team disagrees with it, and we switch it off if that number rises.

Decisions for the process owner

Which cases are in scope? I’d start with payments below an agreed amount that carry at least one reference or name clue. Everything else goes straight to a clerk.
What counts as success? Proposal accuracy and override rate per case type, reviewed monthly by the process owner and internal audit.
When does the agent stop? I’d set an automatic pause if the weekly override rate goes above 15%, until someone understands the cause.

Go deeper

Technical detail for architects and developers

SAP Help for contract accounting describes clarification cases as payments from a posted payment lot that couldn’t be posted to a contract account, so they go to a clarification account and into a clarification worklist. Several processors can work the list in parallel, and items can be reserved for one processor. Clerks can correct and repost, post and clear manually, create a repayment request, or transfer to a clearing account. SAP Learning adds that the system suggests a clarification proposal when a case is opened. Exact behaviour depends on release and configuration, so check your own system.

The tool contract is two Model Context Protocol (MCP) tools and nothing more:

get_case(case_id) is read-only. It returns payment amount, currency, value date, note to payee, payer name, and candidate open items within an agreed tolerance. No bank account numbers beyond what the clerk already sees.
propose_assignment(case_id, contract_account, items[], reasons[], confidence_band) or propose_assignment(case_id, outcome: "needs_review", reasons[]) writes a proposal record to a separate store. It doesn’t touch the payment lot.

The server re-validates every proposal: the contract account must be a candidate returned by get_case, amounts must reconcile, and the case must still be open. The MCP specification says servers must validate inputs and implement access controls, and the spec recommends that clients log tool usage for audit.

Why no post tool? OWASP’s Excessive Agency guidance names too much functionality, permission and autonomy as root causes, and recommends minimal tools, human approval for high-impact actions, and authorisation enforced in downstream systems. Leaving out a post tool covers all of that at once. It’s the one rule I’d defend hardest: the agent proposes, and people post. If a future version needs posting, make it a separate, workflow-owned step under the clerk’s identity, never a tool the model can choose.

Route proposals through a workflow with an approval step, for example an n8n workflow in Joule Studio once it’s available to you. SAP sources differ on n8n availability, so check the Joule capability watch. SAP describes Joule Work as using an enterprise agent gateway that applies identity, access and policy at runtime, including human oversight. The posting itself stays in the standard SAP app, under the clerk’s authorisations.

For the audit log, store per case: input snapshot hash, tool calls with arguments, model version, prompt version, proposal, reasons, clerk decision, edits and the clarification document number. The SAP product post says deployed Joule Studio agents register in SAP AI Agent Hub, with drill-down to execution traces and decision logs. Finance should still own a business-level log of its own.

I’d track proposal accuracy (accepted unchanged, divided by proposals), override rate (edited or rejected, divided by proposals), decline precision (declined cases that truly needed a person), unsafe proposal rate (proposals failing server validation) and handling time. Compare each against the standard clarification proposal.

For the protocol layer behind these tools, see Agents, A2A, MCP and APIs.

Words you’ll hear

FI-CA (Contract Accounts Receivable and Payable): the SAP component for high-volume customer accounts, such as utilities, telecoms and insurance.
Payment lot: a batch of incoming payments, often from a bank statement, posted together.
Clarification case: a payment from a lot that couldn’t be assigned to a contract account automatically.
Clarification worklist: the queue where clerks review and resolve clarification cases.
Contract account: the customer-level account in FI-CA where items and payments are posted.
Override rate: how often a person changes or rejects the agent’s proposal.
Audit log: a complete, time-stamped record of what the agent saw and proposed, and what a person decided.

Keep going

Independent explainer, not affiliated with or endorsed by SAP SE. SAP, Joule and other SAP product names are trademarks of SAP SE.

Frequently asked questions

Why not let the agent post the clearing itself?

Because a wrong assignment moves a customer's money to the wrong account. A proposal tool with no posting tool means the worst an agent can do is suggest something a person rejects.

Does SAP already help with clarification?

Yes. SAP documentation describes a clarification worklist, a system clarification proposal when a case is opened, and an optional SAP Cash Application add-on for contract accounting under a separate licence. Measure any agent against these first.

What should the agent be measured on?

Proposal accuracy on reviewed cases, the override rate by clerks, the share of cases it correctly declines to propose, and handling time per case. Report them per case type, not as one average.

Is this a product SAP ships?

No. This is a custom design you could build in Joule Studio. NextSAP Utilities is fictional, and the tool names are my design names, not SAP APIs.