---
title: State and federal award payment processing
summary: Creates, validates, approves, and pays Fatal, PPD, and PTD state awards and their federal award counterpart, including Social Security offset tracking and award payee/reduction management.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.Payment
reference_type: embedded
operation_id: OP-CP-08
trigger: An adjuster creates or edits a Fatal, PPD, or PTD award for a claim and approves scheduled monthly award payments (state) or a one-time federal award payment
---

# State and federal award payment processing

This operation covers the `clsAward` family (`clsAward`, `clsFatalAward`, `clsPPDAward`, `clsPTDAward`, `clsAwardCollection`) that models a state permanent award and its Social Security offset (`clsAwardSSOffset(Collection)`), the `clsAwardPayment` family (`clsFatalPayment`, `clsPPDPayment`, `clsPTDPayment`) that generates and approves the individual monthly payment transactions against an award, `clsAwardPayeeInfo` for monthly-payee tracking, and the separate `clsFederalAwardPayment`/`clsFederalPayment` classes that issue a one-time federal-equivalent award payment outside the state award structure.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-CP-08 |
| **Trigger** | Adjuster creates/edits an award (`clsFatalAward`/`clsPPDAward`/`clsPTDAward`), manages its Social Security offset, and approves generated award payments; or issues a `clsFederalAwardPayment` |
| **Inputs** | Claim type, award type, effective/order/closure dates, worker birthdate/death date, beneficiaries, average weekly wage, Social Security offset data, payee selections and reduction percentages |
| **Outputs** | `CL_AWARD`, `CL_AWARD_SS_OFFSET`, `CL_STATE_AWARD_MONTHLY_PAYEE` rows; posted award financial transactions (via [Payment posting and totals management](payment-posting-and-totals-management.md)) |
| **Primary components** | `clsAward`, `clsFatalAward`, `clsPPDAward`, `clsPTDAward`, `clsAwardCollection`, `clsAwardSSOffset(Collection)`, `clsAwardPayeeInfo`, `clsFatalPayment`, `clsPPDPayment`, `clsPTDPayment`, `clsFederalAwardPayment`, `clsFederalPayment` |
| **Entry point** | `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAward.vb` |

## Steps

1. **Create the award for the claim's type.** Fatal awards require the claim type to be PTD or Fatal ([BR-CP-028](../business-rules.md#br-cp-028-award-type-must-match-the-claim-type)); PTD awards require the claim type to be PTD.
2. **Enforce type-specific prerequisites** ([BR-CP-029](../business-rules.md#br-cp-029-fatal-and-ptd-award-prerequisites)). A Fatal award requires a worker date of death and at least one beneficiary; a PTD award requires a valid worker birthdate and non-zero average weekly wage.
3. **Distinguish advance vs. scheduled awards** ([BR-CP-030](../business-rules.md#br-cp-030-advance-awards-carry-no-effective-date-and-no-monthly-payments)). An advance Fatal or PPD award carries no effective date and zero total monthly payment; a non-advance award's effective date must be on/after the injury date, with PTD additionally bounded by the closure-order date and PPD bounded to not be in the future.
4. **Insert or update the award** ([SQL-011](../sql/SQL-011.md)/[SQL-039](../sql/SQL-039.md)/[SQL-094](../sql/SQL-094.md), [CL_AWARD](../database-tables.md#cl_award)) and load related closure-order and financial-transaction context ([SQL-040](../sql/SQL-040.md), [SQL-041](../sql/SQL-041.md), [SQL-042](../sql/SQL-042.md), [SQL-043](../sql/SQL-043.md), [CL_BENEFIT_PAYMENT](../database-tables.md#cl_benefit_payment), [CL_CLAIM_CLOSURE_ORDER](../database-tables.md#cl_claim_closure_order), [CL_FINANCIAL_TRANS](../database-tables.md#cl_financial_trans)).
5. **Assign the next award number** ([SQL-003](../sql/SQL-003.md), `SAIF_AWARD_NUM_NEXTVAL` sequence, [DUAL](../database-tables.md#dual)) when a new award is created via `clsAwardCollection`.
6. **Track the Social Security offset if granted** ([BR-CP-034](../business-rules.md#br-cp-034-granted-social-security-offsets-require-complete-date-and-amount-data)). A Granted offset requires a positive monthly amount, effective/order dates on or after the injury date, and an expiration date on or after the effective date; offset date ranges on the same award may not overlap. A Denied status bypasses all of these checks. Persisted via [SQL-013](../sql/SQL-013.md)/[SQL-046](../sql/SQL-046.md)/[SQL-096](../sql/SQL-096.md)/[SQL-119](../sql/SQL-119.md) ([CL_AWARD_SS_OFFSET](../database-tables.md#cl_award_ss_offset)).
7. **Generate the monthly award payment.** `clsFatalPayment`/`clsPPDPayment`/`clsPTDPayment.OnInstantiationComplete` caps the total payment (and every individual payee's share) at $250,000 ([BR-CP-033](../business-rules.md#br-cp-033-award-payment-amounts-are-hard-capped-and-ppd-lump-sum-guidance-applies)).
8. **Apply lump-sum guidance for first PPD awards** ([BR-CP-033](../business-rules.md#br-cp-033-award-payment-amounts-are-hard-capped-and-ppd-lump-sum-guidance-applies)). A first-time PPD award of $6,000 or less should be paid as a lump sum; one over $6,000 should not be paid entirely as a lump sum — enforced as an approval warning/error, not a hard block.
9. **Generate award payees restricted by award type** ([BR-CP-036](../business-rules.md#br-cp-036-award-payee-types-are-restricted-by-award-type)). `clsAwardPayment.GenerateNewPayee` allows only Attorney/Beneficiary/Other/Recovery for Fatal awards and Attorney/Worker/Other/Recovery/Support for PPD/PTD; any other requested payee type is silently downgraded to Other with no error. Monthly payee state persisted through `clsAwardPayeeInfo` ([SQL-012](../sql/SQL-012.md)/[SQL-045](../sql/SQL-045.md)/[SQL-095](../sql/SQL-095.md)/[SQL-118](../sql/SQL-118.md), [CL_STATE_AWARD_MONTHLY_PAYEE](../database-tables.md#cl_state_award_monthly_payee)).
10. **Cap support-order and attorney/other-payee reductions by issue date** ([BR-CP-032](../business-rules.md#br-cp-032-award-reduction-ceilings-by-payee-class-and-issue-date)). Support-order reductions are capped at 25% of the base amount for issue dates on/after January 1, 2012 (50% before); attorney/other-payee reductions are capped at 44%/63% under the same cutover.
11. **Validate the cash card format for award payees** ([BR-CP-035](../business-rules.md#br-cp-035-award-cash-card-format)) — 10 to 16 digits.
12. **Guard against double-payment.** `GetPreviouslyPaidPayees`/`PreviouslyPaidPayeeList` block an award payment approval that overlaps a prior payment to the same payee/provider/reduction for the same payment category and date range on the same award ([BR-CP-037](../business-rules.md#br-cp-037-award-double-payment-guard)).
13. **Post the approved award payment** through [Payment posting and totals management](payment-posting-and-totals-management.md) and record the financial transaction through [Financial transaction and remark management](financial-transaction-and-remark-management.md).
14. **Guard award deletion and status changes** ([BR-CP-031](../business-rules.md#br-cp-031-an-award-cannot-be-deleted-once-payments-have-been-released)). An award cannot be deleted once a payment transaction has been made against it; its status cannot be set to Active while checks against it are still in progress (financial transaction status codes 1-3).
15. **Issue a federal award payment independently.**\* `clsFederalAwardPayment`/`clsFederalPayment` issue a one-time federal-equivalent award payment outside the `clsAward` structure — no dedicated SQL catalog entries were found for these classes, indicating they likely reuse the common posting/financial-transaction persistence path documented in [Payment posting and totals management](payment-posting-and-totals-management.md) and [Financial transaction and remark management](financial-transaction-and-remark-management.md) rather than award-specific tables.

## Process flow

```mermaid
flowchart TD
	Start([Adjuster creates/edits award]) --> TypeCheck{Claim type matches<br>award type?}
	TypeCheck -->|No| Blocked1([Blocked: award type mismatch])
	TypeCheck -->|Yes| Prereq{Type-specific<br>prerequisites met?}
	Prereq -->|No| Blocked2([Blocked: missing prerequisite data])
	Prereq -->|Yes| Advance{Advance award?}
	Advance -->|Yes| NoEffDate[No effective date;<br>zero monthly payment]
	Advance -->|No| EffDate{Effective date<br>within bounds?}
	EffDate -->|No| Blocked3([Blocked: invalid effective date])
	EffDate -->|Yes| SaveAward[Insert/update CL_AWARD;<br>assign award number]
	NoEffDate --> SaveAward
	SaveAward --> SSO{Social Security<br>offset granted?}
	SSO -->|Yes| SSOValidate{Complete date/amount<br>data, no overlap?}
	SSOValidate -->|No| BlockedSSO([Blocked: incomplete offset data])
	SSOValidate -->|Yes| SSOSave[Save CL_AWARD_SS_OFFSET]
	SSO -->|No, Denied| SSOSave2[Save with no additional checks]
	SSOSave --> GenPayment[Generate monthly award payment]
	SSOSave2 --> GenPayment
	GenPayment --> Cap{Amount within<br>$250,000 cap?}
	Cap -->|No| BlockedCap([Blocked: exceeds cap])
	Cap -->|Yes| Payees[Generate restricted<br>award payees]
	Payees --> Reduction[Apply reduction ceilings<br>by payee class/issue date]
	Reduction --> DupCheck{Overlaps a prior<br>payment on this award?}
	DupCheck -->|Yes| BlockedDup([Blocked: previously-paid<br>payee overlap])
	DupCheck -->|No| Post[Post via Payment posting<br>and totals management]
	Post --> Done([Award payment released])
```

## Failure and edge-case behavior

- Award reduction ceilings and PPD lump-sum guidance are enforced with a January 1, 2012 date cutover baked directly into the class code (`PercentLimitChangeDate`), not a configurable table — a future policy change would require a code change.
- The double-payment guard (`GetPreviouslyPaidPayees`) is scoped per award; it does not detect duplicate payments across different awards on the same claim.
- Payee-type downgrading to Other happens silently with no error or warning surfaced to the caller ([BR-CP-036](../business-rules.md#br-cp-036-award-payee-types-are-restricted-by-award-type)), which could mask a data-entry mistake if not caught downstream in the UI.
- No dedicated SQL catalog entries were found for `clsFederalAwardPayment`/`clsFederalPayment`; their persistence path is inferred\* rather than directly traced to a catalogued statement.
- Active-status changes are blocked while payments are "in progress" (financial transaction status codes 1-3), but the award record itself does not expose which specific payment is blocking the transition.

## 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\Payments\StateAwardPayments\clsAward.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAwardCollection.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsFatalAward.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsPPDAward.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsPTDAward.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAwardSSOffset.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAwardSSOffsetCollection.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAwardPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsFatalPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsPPDPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsPTDPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payees\clsAwardPayeeInfo.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\clsFederalAwardPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\clsFederalPayment.vb`