Customer Open Items Missing From Dunning Run
The invoice is usually excluded on purpose, not by error: a dunning block on the customer master or the line item, a missing dunning procedure assignment, grace days not yet elapsed, the minimum dunning interval not reached since the last run, or the item falling below the minimum amount configured for that dunning level. The dunning run log, not the FBL5N list, is what actually tells you why.
Covers why a customer's overdue open items fail to generate a dunning notice in F150 even though the run completes without error. Focuses on the master data and dunning procedure configuration checks that explain exclusion, and the log evidence that separates a real defect from correct behaviour.
Published 16 Sept 2026· 1,229 words
The business symptom
Accounts receivable reports that a specific customer, or a handful of customers, never receive a dunning letter even though the account carries invoices weeks or months past due. It surfaces one of two ways: collections notices the aging report is red for that customer but no dunning notice was ever generated, or the customer calls in confused that a smaller-balance account elsewhere got dunned and theirs did not. Sometimes the account was dunned once and then stalled - it sits at dunning level 1 indefinitely while comparable accounts progress to level 2 or 3 on schedule. The dunning run itself finishes clean, the job log shows no errors, and the immediate assumption is that F150 is broken, when in most cases the run correctly excluded the account or the specific line item given its current master data or open item attributes.
The configuration behind it
Ordered by how often each one turns out to be the actual reason, starting with account-level exclusions and working down to item-level timing and configuration thresholds.
- Dunning block set on the customer master company code segment - excludes the entire account from every run regardless of how overdue the items are.
- Dunning block set at the line item level - one invoice stays out while the rest of the account dunns normally, often a leftover from a resolved dispute where the block was never cleared.
- No dunning procedure assigned in the customer master, or the field went blank after a master data change - the account is invisible to F150 even with overdue items.
- Item not yet overdue by the required margin - grace days configured on the dunning procedure level, or the net due date calculation from payment terms, push the effective due date past the run's key date.
- Dunning frequency not yet elapsed - the account was dunned in a prior run and the configured minimum number of days between runs has not passed, so F150 skips it even though the item is still open.
- Minimum amount per dunning level not met - the item balance sits below the threshold configured for that level on the dunning procedure, so it is excluded from that particular run.
- Dunning area mismatch - the dunning area on the customer master differs from the dunning area used in the F150 parameter set, common where dunning areas separate sales lines or business units.
- Selection parameters on the F150 run itself exclude the account - company code range, account range, or a free selection field unintentionally filters the customer out.
- Special G/L transactions such as down payments or security deposits excluded because the dunning procedure is not configured to include that special G/L indicator.
- Item already cleared, or its clearing date falls before the run's key date, so it no longer counts as open at the point the selection runs.
What to check
Work from the item outward to the configuration, since most cases resolve at the master data or parameter level before any config change is needed.
- FBL5N on the customer - check the due date, the dunning block field, the current dunning level, and the last dunned date on the specific line that is missing.
- XD03 or FD03 - customer master company code view, confirm the dunning procedure field is populated, check the dunning block field and the dunning area assigned.
- F150 - rerun the same selection in test mode and open the dunning log for that account; the log states the exclusion reason explicitly when the account was considered and rejected.
- FBMP - review the dunning procedure assigned to the account: intervals between dunning runs, grace days per level, minimum amounts per level, and whether special G/L indicators are included.
- The F150 parameter set used for the prior production run - company code range, account range, and free selections, to rule out the account being filtered out at selection.
- Compare the dunning area on the customer master against the dunning area entered on the F150 parameter screen.
How to prove it in the data
Pull the F150 dunning log for the run in question and search for the customer account - the log records every account considered along with the reason for exclusion, which is the only place that turns a business complaint into a documented cause. Cross-check with FBL5N filtered on that customer showing the dunning block field, dunning level, and last dunned date columns, and compare the due date shown there against the run's key date used in F150.
Resolution path
The fix depends entirely on which cause the log points to, and the two categories - master data and configuration - require very different handling.
- Dunning block on customer or line item: remove the block in the master record or on the item once the underlying reason (dispute, hold) is genuinely resolved; this is a data change, no transport needed, but requires the credit or collections owner's sign-off, not a blind removal by the person running F150.
- Missing or blank dunning procedure: correct the customer master field; this is a data fix, apply it directly or via a mass maintenance transaction if several accounts are affected.
- Grace days or frequency not elapsed: no fix required, this is correct behaviour; if the business wants a shorter interval, that means changing the dunning procedure configuration in FBMP, which is a config change requiring transport and testing across all accounts on that procedure.
- Minimum amount threshold: confirm with the business the amount is intentional before changing it; adjusting it in FBMP affects every customer on that dunning procedure, not just the one being investigated.
- Parameter selection error on the F150 run: correct the selection variant for the next run; no config or transport involved, just re-entering the run correctly.
The fix people try first (and why it fails)
The reflex fix is to issue the dunning letter manually outside F150, or to lower the minimum amount and grace days globally on the dunning procedure just to force the one account through. The manual letter fixes nothing structurally - the account will silently drop out again next period for the same reason. Lowering thresholds on the shared dunning procedure pulls in unrelated accounts that were correctly excluded, generating a wave of premature dunning letters to customers who are within their agreed grace period, which creates a second, larger complaint.
Whose problem this is
Dunning blocks and missing procedure assignments on the customer master are owned by accounts receivable or credit management, since they reflect a business decision about that account. Changes to the dunning procedure itself - intervals, grace days, minimum amounts - are owned by FI configuration and go through transport and regression testing because they affect every customer on that procedure. The handover note should state the account, the exact exclusion reason from the F150 log, and whether the fix was a data change or a configuration change.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-functional-issues/customer-open-items-not-appearing-in-the-dunning-runERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.