# SAP Credit Risk Analyzer: Counterparty Limits in TRM

Source: https://gravam.com/blog/sap-credit-risk-analyzer
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: The SAP TRM Credit Risk Analyzer: limit types and characteristics, attributable amounts, the limit check at deal entry, and TBL1, TBLB and KLNACHT.

**The Credit Risk Analyzer is the SAP TRM component that measures counterparty/credit risk and manages limits — quantifying exposure to each counterparty as an _attributable amount_, checking deals against limits, and flagging breaches.** It's how SAP turns the [counterparty-limit discipline](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) from a policy document into an enforced system control. Treasury policy decides _how much_ exposure to any one bank or partner is acceptable; the Credit Risk Analyzer is what makes the dealing actually _stay_ within it — measuring exposure, holding the limits, and checking every deal against them. It's one of the three [Analyzers](https://gravam.com/blog/what-is-sap-treasury-and-risk-management), and the one that keeps a good policy from being just a good intention.

## What it is

Every treasury runs on [counterparty limits](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) — caps on how much it will be exposed to any single institution, so no one failure is catastrophic. The Credit Risk Analyzer is where those limits live and bite in SAP: it knows the current exposure to [each counterparty](https://gravam.com/blog/business-partner-configuration-sap-treasury), holds the limit for each, and enforces the relationship between them. SAP frames it as measuring, analyzing and controlling _default risk_: the loss if a business partner doesn't meet its obligations.

## What it does

Three connected jobs: **measure exposure** to each counterparty across its deals and positions, **maintain the limits** policy has set (per counterparty, often by other dimensions too), and **check transactions** against them as they're entered, so a deal that would breach is caught.

## The objects you actually configure

This is the part generic descriptions skip. Five objects carry most of the weight:

- **Limit characteristics** — the dimensions a limit can be defined on. SAP delivers seven direct characteristics for the default risk limit: company code, business partner, limit product group, portfolio, trader, currency and monitoring unit.
- **Limit types** — a combination of limit characteristics, such as business partner plus limit product group. The limit type decides which transactions a limit collects; a limit type filter can narrow it further with ranges.
- **Limit product groups** — your grouping of products for limit purposes; walkthroughs typically split investments, derivatives and cash balances.
- **Determination procedure and default risk rule** — the default risk rule is derived per transaction, and each combination of the two specifies the formula for the attributable amount.
- **Netting groups and collateral agreements** — a netting group defines which business partner's transactions are balanced and carries its own default risk rule; [collateral agreements](https://gravam.com/blog/isda-csa-and-collateral-management) assigned to it reduce attributable amounts, and with them limit utilization.

| Code | SAP's name | What you use it for |
| --- | --- | --- |
| TBL1 | Manage Limits | Create and maintain limits (Credit Risk Analyzer > Master Data) |
| TBLB | Review Limit Utilizations | The limit utilization overview — what is using each limit right now |
| KLNACHT | End-of-Day Processing | Recalculate attributable amounts and update every utilization |
| KLNACHT2 | Execute Postprocessing | The error messages of the end-of-day run |

The check at deal entry has no transaction of its own: it's switched on in Customizing (Credit Risk Analyzer > Basic Settings > Activate Integrated Default Risk Limit Check) and runs inside the Transaction Manager.

TBL1, TBLB and KLNACHT match the [transaction-codes reference](https://gravam.com/blog/sap-treasury-transaction-codes). Tables such as KLNT01 and KLMAXLIMIT are named in SAP's data-protection documentation but not described — the [tables reference](https://gravam.com/blog/sap-treasury-tables) explains why they get no rows.

## What it actually calculates: the attributable amount

Every limit is compared against the **attributable amount** — SAP's measure of the default risk that arises when a transaction is concluded, meant to reflect expected and unexpected loss. It's a formula: a base key figure with parameters such as add-on factors and default probabilities. For counterparty and issuer risk the base is typically the net present value or the nominal amount; for settlement risk it's usually the repayment amount. A limit's **utilization** is then simply the sum of the attributable amounts of all transactions assigned to that limit through their characteristic values.

Which risk category a product draws on is configuration: an SAP-authored walkthrough on SAP Community sets FX spots to settlement risk only and FX forwards to credit risk — a decision that determines which limit a spot-heavy day consumes.

## Limit checking is the point

> A counterparty limit you only check _after_ the deal is done isn't a control — it's a report of the breach you already have. The Credit Risk Analyzer's value is checking _before_, at the point of dealing, so the limit actually stops something.

The heart of it is **checking at the point of dealing**. With the integrated check active, each transaction is checked when it is created in the Transaction Manager: the system determines attributable amounts for every risk category released for the single transaction check, then checks the maximum risk commitment period, internal and external limits, and the critical limit utilization — the percentage above which an early warning fires. The result comes back as a traffic light. The same check can also test a deal that isn't in the system yet, before it is struck.

Be precise about what a breach does. In SAP standard, a limit excess raises a **warning**, and a "workflow is active" setting can route a message to a responsible person; the deal can still be saved. A hard stop is a deliberate extra configuration decision, not a default — which is why the reaction has to be designed with the [risk policy](https://gravam.com/blog/treasury-risk-management-policy), not in a separate room.

## End of day: KLNACHT

The check at deal entry keeps utilizations current during the day; **end-of-day processing (KLNACHT)** is the final update. It revalues all transactions and positions, including external transactions entered for deals outside the Transaction Manager — so an NPV-based attributable amount moves with the market even if nobody touched the deal. It usually runs as a scheduled job; KLNACHT2 shows what failed, TBLB shows the result.

## How it connects to the Transaction Manager and market data

The Credit Risk Analyzer holds no deals of its own. It reads the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager): when a deal is created, its limit characteristics and attributable-amount parameters are derived onto the financial object the Analyzer evaluates. Two upstream things are therefore decisive. The [Business Partner](https://gravam.com/blog/business-partner-configuration-sap-treasury) is the counterparty the limit sits on, so a duplicated partner splits exposure across two records. And where the attributable amount is NPV-based, it's only as right as the [market data](https://gravam.com/blog/sap-treasury-market-data-management) behind the valuation.

## Why it matters

The Analyzer is where the [counterparty discipline](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) — set limits, diversify, monitor, act early — stops depending on someone remembering to look at a spreadsheet. Counterparty risk [feels like nothing until it's everything](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury); when policy says "no more than X to any one counterparty," this is what holds the line, deal by deal. It's the difference between having a counterparty limit and _enforcing_ one.

## Why counterparty limits become theatre

- **Limits not maintained.** Limits set at go-live and never updated in TBL1 as counterparties and appetite change.
- **Warnings nobody owns.** SAP's standard reaction to an excess is a warning; without the workflow switched on and someone accountable for the result, it gets clicked through and the control is theatre.
- **Exposure measured wrongly.** A determination procedure or default risk rule that doesn't capture true exposure — or a product mapped to the wrong risk category — so limits are checked against the wrong number.
- **End-of-day run nobody watches.** KLNACHT fails, KLNACHT2 isn't checked, and TBLB shows stale utilizations.
- **Policy and config designed apart.** Limits in the system that don't match the actual risk policy, so neither is trustworthy.

Maintain the limits, measure exposure correctly, check at the point of dealing with a deliberate warn/stop decision, and keep the configuration aligned to policy — and the Credit Risk Analyzer becomes the enforcement layer that makes counterparty limits real. Policy sets the appetite; this is what holds the dealing to it, automatically, at the one moment a limit can actually prevent something.

***

_See also [counterparty and credit risk in treasury](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) and [the treasury risk management policy](https://gravam.com/blog/treasury-risk-management-policy)._

## Primary sources

SAP S/4HANA on-premise/private edition (the classic transactions named here are GUI transactions; several SAP Help pages cited come from the SAP ERP and SAP Simple Finance documentation sets). Verify against your release. The 2026-09-25 fact-check used cross-checked excerpts of SAP Help, SAP Community and SAPinsider pages returned by search, because SAP Help could not be opened directly from the verification environment; claims that could not be confirmed in at least one SAP-published source were left out.

- SAP Help — Credit Risk Analyzer (Treasury and Risk Management, SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/bc08da531198434de10000000a174cb4.html
- SAP Help — Default Risk and Limit System (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/af02c753b1081d4be10000000a174cb4.html
- SAP Help — Limit Types (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/c009da531198434de10000000a174cb4.html
- SAP Help — Attributable Amount Determination (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/f909da531198434de10000000a174cb4.html
- SAP Help — Single Transaction Check (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/bb09da531198434de10000000a174cb4.html
- SAP Help — Checking New Transactions (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/c508da531198434de10000000a174cb4.html
- SAP Help — Updating Limit Utilizations (Credit Risk Analyzer) — accessed 2026-10-18 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/f508da531198434de10000000a174cb4.html
- SAP Help — End-of-Day Processing (Credit Risk Analyzer) — accessed 2026-10-18 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/0dbd9753858ced23e10000000a174cb4.html
- SAP Help — Netting (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/1a0ada531198434de10000000a174cb4.html
- SAP Community — Credit Risk Analyzer: Limits Management, Money Market (Fixed Deposits) and Forex (Spots) — accessed 2026-09-25 — https://community.sap.com/t5/financial-management-blog-posts-by-sap/credit-risk-analyzer-limits-management-money-market-fixed-deposits-and/ba-p/14277230
- SAPinsider — A Guide to SAP's Credit Risk Analyzer — accessed 2026-09-25 — https://sapinsider.org/a-guide-to-saps-credit-risk-analyzer/

## Questions this article answers

**Q: What is the SAP Credit Risk Analyzer?**

The Credit Risk Analyzer is the component of SAP Treasury and Risk Management that measures counterparty and credit risk and manages limits. It quantifies how much exposure the company has to each counterparty (banks and trading partners) as attributable amounts, maintains the limits set for them, and checks transactions against those limits, flagging deals that would breach them. In effect, it's how SAP enforces the counterparty-limit discipline that treasury policy defines, turning limits from a document into a system control.

**Q: How does the Credit Risk Analyzer manage limits?**

Limits are defined on limit types, which combine limit characteristics such as company code, business partner, limit product group, portfolio, trader, currency and monitoring unit. Each transaction produces an attributable amount, and a limit's utilization is the sum of the attributable amounts of the transactions assigned to it. With the integrated single transaction check active, a new deal in the Transaction Manager is checked against its limits as it is entered; end-of-day processing (KLNACHT) then recalculates every utilization. In SAP standard, an excess raises a warning and can trigger a workflow; a hard stop is a separate, deliberate configuration decision.

**Q: How does the Credit Risk Analyzer relate to counterparty risk management?**

The Credit Risk Analyzer is the SAP implementation of counterparty risk control. Counterparty risk management as a discipline means setting limits on how much exposure you'll carry to any single bank or partner, diversifying, and monitoring — and the Credit Risk Analyzer is where those limits become enforceable in the system: exposure is measured, limits are held, and deals are checked against them automatically. The policy decides how much risk is acceptable; the Credit Risk Analyzer makes sure the dealing actually stays within it.

**Q: Which transaction codes does the SAP Credit Risk Analyzer use?**

The working set is small. TBL1 (Manage Limits) creates and maintains limits, TBLB (Review Limit Utilizations) shows what is using them, KLNACHT (End-of-Day Processing) recalculates attributable amounts and utilizations, and KLNACHT2 (Execute Postprocessing) shows the error messages of that run. The limit check at deal entry has no transaction of its own: it runs inside the Transaction Manager when the integrated default risk limit check is activated in Customizing.