General
8 Min Read

SAP FICA Dunning: From Configuration to Execution (End-to-End Guide)

Aryan Yadav

Aryan Yadav

December 28, 2025

SAP FICA Dunning: From Configuration to Execution (End-to-End Guide)

In SAP FI-CA, which acts as the financial backbone for SAP BRIM & ISU, dunning refers to the structured process of following up on overdue receivables. It automatically notifies business partners when payments are past due and can escalate the situation by applying late payment charges or triggering actions such as service restrictions when required.

To master "Dunning" from end to end, we divide this article in 4 phases:

  1. Master Data Assignment

  2. Configuration (SPRO)

  3. Execution Transactions

  4. Technical Enhancements (ABAP - Optional for Functionals)

Master Data Assignment

In this module of "Master Data Assignment" we will focus on two important and most critical part of Dunning, i.e.,

  1. Dunning Procedure

  2. Dunning Lock

Dunning Procedure : Dunning procedure is like a Rule Book which defines or decides how a customer will get treated when they owe you money. In simple terms "How aggressively should be we with the customer?". In database, it is a 4 character key(e.g. 0001, VIP1, TEL1). We configure dunning procedure in SPRO which we cover later in this article in "Configuration" module, where we define main parameters: levels, charges, activities, limits, grouping. We maintain dunning procedure mainly on three levels in hierarchy: Line Item > Contract > Contract Account (FKKVKP-MAHNV)

Dunning Locks: Dunning locks are used to stop or hold dunning for a customer, contract or open item. We can assign locks at these 4 levels: Contract Account (FKKVKP-MANSP), Contract, Line Item (DFKKOP-MANSP), Business Partners. The hierarchy is as follow: Line Item > Contract > Contract Account > Business Partner.

How it works?

Before moving ahead lets understand how the flow works for Dunning Procedure & Dunning Locks. Dunning procedure follows "Static Stamp" while dunning lock follows "Dynamic Check" approach. lets understand this in details.

Dunning procedure follows a static stamp (stamped at the time of posting). At the moment CI posts an invoice and open items are created in FICA, the system checks which dunning procedure is maintained on the Contract, and the same dunning procedure gets copied to the open line item. In case no dunning procedure is maintained at the Contract level, the system checks at the Contract Account level, and if no dunning procedure is maintained at the Contract Account level as well, then no dunning procedure gets copied to the open line item, and this open item will never get picked for dunning.

While execution of the dunning process, the system checks at item level only; it never checks at Contract or Contract Account level for the dunning procedure. So, in case in the future the dunning procedure gets changed for the Contract or Contract Account, it will not impact the already created open items.

On the other hand Dunning Locks follows "Dynamic Checks", when an open item get created in FICA, by default the dunning lock always remains off. When the dunning proposal run(FPVA) runs, it check dynamically at each level by following the hierarchy: line item > Contract, Contract Account > Business Partner. In case any of these have lock then it will not picked up for dunning. But there is one case where the system marked the dunning lock at the time of creation when we create an open item the system automatically adds a dunning lock on the item level, which needs to remove manually to make it eligible for dunning.

Configuration (SPRO)

SPRO Path: Financial Accounting (New) -> Contract Accounts Receivable and Payable -> Business Transactions -> Dunning

  1. Define Dunning Activities (The "Action" Library)

Path: .... -> Dunning -> Configure Dunning Activities

Define Activity Key: Create a 4-digit key. Z001: Print Reminder, Z002: Charge Fee, Z003: Lock Service

Assign Function Module: Select Z001 & Assign FM: FKK_SAMPLE_0350 (Standard Print). If you created a custom FM Z_API_CALL_BLOCK_SIM, you can assign it to Z003 here.

Table Updated: TFK047I

  1. Define Charge Schedule (The "Money" Rules)

Path: .... -> Dunning -> Configure Charge Schedules for Dunning Procedure

We need to define the logic for late fees before we can attach it to the dunning level.

  • Create Schedule ID: e.g., SCH1.

  • Define Scales: Select Currency USD, From Amount: 0.01 -> Charge: 5.00, From Amount: 100.00 -> Charge: 15.00

  • Postings: We have to define if this is an "Interest" charge or a "Dunning" charge.

  • Table Updated: TFK047M (Amounts) / TFK047C (Header).

  1. Define Dunning Procedure (The "Header")

Path: .... -> Dunning -> Configure Dunning Procedure

  • New Entry: ID ZTEL (Telecom Standard).

  • Dunning Interval: 14 Days. (Wait 14 days between runs).

  • Grace Days: 2 Days. (If due date is Monday, don't dun until Thursday).

  • Dunning Level: 0 (Optional: Do we send a "Level 0" reminder before they are technically late? Usually No).

  • Table Updated: T047A

  1. Configure Dunning Levels (The "Heart")

Path: .... -> Dunning -> Configure Dunning Procedure

This is where we link Step 1, 2, and 3 together. Inside the dunning procedure screen ( ZTEL) , click dunning levels:

  1. For Level 1:

  • Days in Arrears: 5 (Trigger point).

  • Print Dunning Notice: [Checked] (Enables output).

  • Interest: [Unchecked] (No interest yet).

  • Dunning Activity: Assign Z001 (From Step 1).

  • Dunning Charges: Assign SCH1 (From Step 2).

  1. For Level 2:

  • Days in Arrears: 20.

  • Dunning Activity: Assign Z002 (Charge Fee) + Z001 (Print).

  • Dunning Charges: Assign SCH1 (Higher fee might apply based on scale).

Table Updated: T047B

  1. Configure Groupings (The "Bundling")

Path: ... -> Dunning -> Grouping of Items -> Define Grouping Variants

  • Create Variant: ZSTD.

  • Assign Fields: GPART (Business Partner), VKONT (Contract Account), WAERS (Currency)

  • Logic: If a BP has 2 contract accounts, they get 2 letters. If you remove VKONT, they get 1 letter for both accounts combined.

  • Table Updated: TFK047G

  1. GL Account Determination (The "Hidden" Step)

Path: .... -> Basic Functions -> Postings and Documents -> Document -> Define Account Assignments for Automatic Postings -> Automatic G/L Account Determination

When we configured Charges, the system needs to know: "Credit Revenue, Debit Customer."

  • Select Transaction: 0030 (Dunning Charges).

  • Select Sub-Transaction: 0010 (Standard Charge).

  • Assign G/L: Map it to your "Admin Fee Revenue" GL Account.

  • Table Updated: T030

Execution Transactions

In SAP FICA, dunning is a mass process because FICA is designed to handle millions of records, SAP does not process them in a single thread. Instead, it uses Parallel Processing to split the workload to split the workload across multiple application servers.

Dunning is two-step execution process, it divides in two distinct transaction codes(FPVA & FPVB) which needs to be run in order.

FPVA - Dunning Proposal Run: This run identifies who is late. But it do not send any dunning letter or any other activity. It fetch open items from DFKKOP table and checks for locks, days in arrears and determine the dunning levels based on the configuration. Then it populates "Dunning History" table FKKMAKO (Header) and FKKMAZE (Item). Proposals created in FKKMAZE table can be deleted or re-run FPVA again as per requirement or discrepancy.

FPVB - Dunning Activity Run: When we execute the FPVB it takes run date and run id we provide to it and reads the Dunning History tables FKKMAKO & FKKMAZE and filter out the deleted or blocked proposals.

For every dunning group (e.g. Contract Account), it looks at the dunning level determined in the proposal created by FPVA. It reads TFK047I (Dunning Activities) to find out the activity to perform. For example: What is assigned to procedure Z01, level 2? and answer received "Activity 0001 (Print) and Activity 0020 (Charge)".

(Optional - For Functionals) - If the activity is "Print" it calls the FM linked to Print Workbench; e.g. FKK_WRITE_CORR. If the activity is "Charge", it calls the FM to post the document; e.g. FKK_CREATE_CHARGE_DOC.

Once the activities are successful, FPVB updated the tables: It updated the dunning level of open item in DFKKOP-MAHNS, it creates a record in table DFKKCOH in case any letter was required. It creates a record in DFKKOP & DFKKKO tables if any fees was charged. It updated status to "Executed" in FKKMAKO.

Please note for every item it checks the dunning activity assigned to it. Unlike FPVA, which can be deleted and re-run multiple times, FPVB creates permanent records. To reverse it we have to run a specific transaction FPVC.

Additional Knowledge: FPVB never sends any dunning letter to the customer. It creates an entry in DFKKCOH & DFKKCOI (Correspondence tables) in case dunning letter is required to sent.

We use FPCOPARA transaction code to fetch the pending item from DFKKCOH table and process them by generating and sending PDFs and update the status in DFKKCOH table.

To know more about FPCOPARA Functional & Technical Understanding, click here (link to be update soon).

Technical Enhancements (ABAP - Optional for Functionals)

In SAP FICA we do not modify the standard code. Instead, SAP provides a framework of Events FQEVENTS where we inject our custom code.

If we go to transaction FQEVENTS, we can fund hundred of hooks. For dunning we have 3 most important in terms of dunning:

  1. Event 0300: Dunning Proposal: It runs inside FPVA for every single item before it added to the proposal.

  2. Event 0360: Grouping: It also runs inside FPVA after the items are selected for proposal but before the level is determined. Here we can add custom logic to handle how should system groups the items.

  3. Event 0350: Dunning Activities: It runs inside FPVB when level is reached an activities needs to execute. For example: If Level 3 is reached, call a REST API to suspend the user's subscription.

Debugging Mass Activities:

  1. Go to FPVA (or FPVB).

  2. Enter your Run Date and ID.

  3. Go to the Technical Settings tab. Check the box "Debug" (sometimes labeled "Wait" or "Dialog Mode"). This forces the run to execute in the foreground (Dialog mode) instead of background.

  4. In the "Custom Selections" tab, filter for ONE Business Partner. Never run debug mode for the whole database! It will time out.

  5. Your session will now open the debugger when it hits your breakpoint in Event 0300 or 0350.

Along with this we have EFRM - FICA_DUNNING form class which used by FPCOPARA to generate the letters, this topic we cover in different article, click here (link to be updated soon).

Authenticity Audit

Verified by the MythVortex Archive board for intellectual integrity. This entry is cataloged under the General division.