---
title: Payment list queries and NDR claim data retrieval
summary: Retrieves pending-approval and approver payment worklists with confidentiality masking, enforces payment authority limits, and retrieves non-disabling reimbursement claim amounts from the claim-data API.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.Payment
reference_type: embedded
operation_id: OP-CP-14
trigger: An adjuster or approver opens a payment worklist, or the system checks a user's payment authority, or a refund needs non-disabling reimbursement claim amounts
---

# Payment list queries and NDR claim data retrieval

This operation covers `clsPaymentList`/`clsPaymentListCollection` (read-only payment worklists for pending approval and by-approver views), `clsPaymentUser` (payment initiate/approve authority limits), and the non-disabling reimbursement (NDR) claim-amount lookup logic embedded in `clsNdRefund` (the nested `clsNDRClaimAmountsResponse` helper and `GetNDROverMax`/`SQLCompareNDRCurrentToMax`), used by [Refund adjustment processing](refund-adjustment-processing.md).

| Field | Value |
| --- | --- |
| **Operation ID** | OP-CP-14 |
| **Trigger** | Adjuster/approver requests a payment worklist; a payment initiation/approval checks the acting user's authority; a refund requests NDR claim amounts |
| **Inputs** | Mail/approver ID, business function and payment amount (authority check), claim ID (NDR lookup) |
| **Outputs** | Read-only payment-list rows (with confidentiality masking applied); authority pass/fail result; NDR claim amount figures |
| **Primary components** | `clsPaymentList`, `clsPaymentListCollection`, `clsPaymentUser`, `clsNdRefund` (NDR claim-amount retrieval) |
| **Entry point** | `Business\SAIF.Business.Claim.Payment\clsPaymentListCollection.vb` |

## Steps

1. **Retrieve payments pending approval.** `clsPaymentListCollection` executes `pk82394_claim_benefit.getPaymentsByApprover` ([SQL-073](../sql/SQL-073.md)) for one worklist view.
2. **Retrieve a second by-approver payment view.** A related overload of the same stored procedure ([SQL-074](../sql/SQL-074.md)) returns a differently-scoped by-approver list. Together, the two overloads let the caller filter the worklist by whether the acting user is the payment's approver or its initiator ([BR-CP-002](../business-rules.md#br-cp-002-payments-may-be-filtered-by-approver-vs-initiator-role)).
3. **Retrieve pending awards.** `pk82394_claim_benefit.getPendingAwards` ([SQL-075](../sql/SQL-075.md)) returns awards awaiting approval, feeding the same worklist surface alongside other pending payment types.
4. **Mask confidential worker identity** ([BR-CP-071](../business-rules.md#br-cp-071-confidential-worker-names-are-masked-on-payment-lists)). `clsPaymentList.WorkerName` returns the literal "Confidential" instead of the worker's real name whenever the underlying claim is flagged as a worker conflict.
5. **Check the acting user's payment authority** ([BR-CP-072](../business-rules.md#br-cp-072-payment-authority-is-limited-by-expiration-date-and-configured-maximum-amount)). `clsPaymentUser.HasAuthority`/`PaymentAuthorities` exclude any authority limit past its expiration date and permit initiating or approving only up to that limit's configured maximum amount, returning `ApprovalErrors.AuthorityLevel`/`NotAllowedToApprove` when the amount or expiration is out of bounds.
6. **Retrieve NDR claim amounts primarily from the claim-data API.**\* `clsNdRefund.GetNDROverMax` calls the external claim-data API endpoint `v1/GeneralClaimData/Claim/Nondisabling/ReimbursementAmounts` via `GetApiRouteMaxNdr`, deserializing the response into the nested `clsNDRClaimAmountsResponse`/`NdrClaimDataResponse` types, and compares `TotalRecoveredAmount + NDRAmount` against `MaxReimbursementAmount` per claim.
7. **Fall back to a local comparison query when needed.** `clsNdRefund.SQLCompareNDRCurrentToMax` ([SQL-067](../sql/SQL-067.md)) computes the same current-vs-maximum comparison directly against local tables ([CLAIM_NON_DISAB_REIMB_MAX](../database-tables.md#claim_non_disab_reimb_max), [CL_FINANCIAL_TRANS_DTL](../database-tables.md#cl_financial_trans_dtl), [CL_INJURY_CLAIM](../database-tables.md#cl_injury_claim)) as an inline alternative to the API call.
8. **Compare recovered amount to the statutory maximum** ([BR-CP-073](../business-rules.md#br-cp-073-non-disabling-reimbursement-is-capped-against-the-cumulative-recovered-amount)). This comparison — and the resulting over-maximum flag consumed by [Refund adjustment processing](refund-adjustment-processing.md) — is fully embedded in `clsNdRefund`; it is documented here as the data-retrieval side of that check, since it is the SQL/API-facing logic rather than the refund-creation workflow itself.

## Process flow

```mermaid
flowchart TD
	Start([Adjuster/approver opens<br>payment worklist]) --> WhichList{Which list?}
	WhichList -->|Pending approval| ProcA[Call getPaymentsByApprover]
	WhichList -->|By-approver view| ProcB[Call getPaymentsByApprover overload]
	WhichList -->|Pending awards| ProcC[Call getPendingAwards]
	ProcA --> Mask{Claim flagged as<br>worker conflict?}
	ProcB --> Mask
	ProcC --> Mask
	Mask -->|Yes| Confidential[Worker name shown<br>as Confidential]
	Mask -->|No| RealName[Worker name shown as-is]
	Confidential --> Rendered([Worklist rendered])
	RealName --> Rendered
	AuthStart([Payment initiate/approve<br>requested]) --> AuthCheck{Within authority limit<br>and not expired?}
	AuthCheck -->|No| AuthBlocked([Blocked: authority error])
	AuthCheck -->|Yes| AuthOK([Initiate/approve allowed])
	NDRStart([Refund requests<br>NDR claim amounts]) --> CallAPI[Call claim-data API<br>or local comparison query]
	CallAPI --> Compare{Recovered + proposed ><br>statutory maximum?}
	Compare -->|Yes| FlagOverMax([Claim flagged<br>for adjuster review])
	Compare -->|No| NoFlag([No flag raised])
```

## Failure and edge-case behavior

- The confidentiality mask only substitutes the worker's name string; it does not remove other potentially identifying fields (payment amount, dates, payee type) from the same worklist row, so downstream consumers relying on the mask for full anonymization should not assume it is comprehensive.
- Authority limits are checked purely by amount and expiration date at the moment of the check; a limit that expires between initiation and approval of the same payment would need to be re-checked at approval time to catch that change (consistent with the check being invoked separately at each stage).
- `clsNdRefund`'s dependency on an external claim-data API for the primary NDR lookup path means claim amount figures reflect that API's data as of the call, not necessarily the same instant as the payment library's own transaction data — a timing/consistency consideration flagged as inferred\* rather than directly confirmed in this layer. The local `SQLCompareNDRCurrentToMax` fallback avoids that dependency but was not confirmed as the primary path.
- No SQL catalog entries exist for a distinct `clsPaymentList` (non-collection) persistence path; it is a read-only projection over the collection's stored-procedure results.

## Related documentation

- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.md)
- [Database tables](../database-tables.md)

> **Note:** Statements marked with `*` were inferred from code structure, naming
> conventions, or contextual evidence where direct confirmation was not available
> in source artifacts.

## Sources

- `Business\SAIF.Business.Claim.Payment\clsPaymentListCollection.vb`
- `Business\SAIF.Business.Claim.Payment\clsPaymentList.vb`
- `Business\SAIF.Business.Claim.Payment\clsPaymentUser.vb`
- `Business\SAIF.Business.Claim.Payment\Adjustments\Refunds\clsNdRefund.vb`
- `Business\SAIF.Business.Claim.Payment\NdrClaimData.vb`