---
title: SAIF.Business.Claim.Payment business rules
summary: Business rules enforced by SAIF.Business.Claim.Payment.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.Payment
reference_type: package
---

# SAIF.Business.Claim.Payment business rules

This page captures business rules enforced by `SAIF.Business.Claim.Payment`.

## BR-CP-001: Optimistic concurrency on all stored-procedure-based operations

| Field | Value |
| --- | --- |
| Statement | Optimistic concurrency on all stored-procedure-based operations |
| Trigger | After* lifecycle |
| Enforcement | All business objects |
| Outcome | Error message on RowsAffected ≠ 1 |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-002: Payments may be filtered by approver vs initiator role

| Field | Value |
| --- | --- |
| Statement | Payments may be filtered by approver vs initiator role |
| Trigger | Payment list retrieval |
| Enforcement | `clsPaymentListCollection` stored proc selection |
| Outcome | Different result sets by role |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-003: Overpayment recovery balance determines eligibility

| Field | Value |
| --- | --- |
| Statement | Overpayment recovery balance determines eligibility |
| Trigger | Overpayment check |
| Enforcement | `pk82395_overpayments.getRecoverableBalance` (referenced in test) |
| Outcome | Threshold-based eligibility* |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-004: Payee address must be valid before a transaction can save

| Field | Value |
| --- | --- |
| Statement | A financial transaction cannot save unless the payee's address is valid for its payee type: worker/beneficiary payees require a validated address; attorney/other/medical-provider payees require address line 1 (plus city and state unless the address is foreign). |
| Trigger | Level-one rule check on `AddressLine1`, unless `IgnoreBusinessRules` is set or the transaction already exists with a valid address |
| Enforcement | `clsFinancialTrans.ValidAddress` |
| Outcome | Broken rule "Error: Worker/Beneficiary/Provider address is invalid \<PayeeFullName\>"; save blocked |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-005: Reimbursement program precedence on a transaction detail

| Field | Value |
| --- | --- |
| Statement | A transaction detail's reimbursement program is set to Supplemental Disability when the transaction is SD; otherwise to Retro Reserve when the detail carries a retro reserve amount; otherwise to NCE when the claim is an NCE claim. |
| Trigger | Immediately before insert of the parent transaction |
| Enforcement | `clsFinancialTrans.SetReimbursementCodeOverrides` (called from `ApplyValueChecks`) |
| Outcome | `ReimbursementProgramCode` overwritten with the SD/RR/NCE code |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-006: Claim cost category suppressed for non-chargeable or reimbursable details

| Field | Value |
| --- | --- |
| Statement | A transaction detail carries no claim cost category when it is non-chargeable, when the payee is Recovery, or when it belongs to a reimbursable program (Retro Reserve, Own Motion, Pre-1986 Vocational, Supplemental Disability, EAIP); a chargeable "addition to computation" line is instead categorized as chargeable expense. |
| Trigger | Immediately before insert of the parent transaction |
| Enforcement | `clsFinancialTrans.SetCostCategoryOverrides` / `IsReimbursable` |
| Outcome | `ClaimCostCategoryCode` cleared or set to `CHE` |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-007: New financial transactions default to Released, indemnity, current-user initiated

| Field | Value |
| --- | --- |
| Statement | Every newly created financial transaction is stamped Released status, indemnity display code, today's issue/entry date, and the logged-on user as initiator, and snapshots the claim's jurisdiction, status, type, coverage, injury date, policy, tail-coverage, preferred-worker, federal-benefit, NCE, HWR and own-motion values as of creation time. |
| Trigger | `Create()` |
| Enforcement | `clsFinancialTrans.Create` / `SetHistory` |
| Outcome | Field defaults and historical snapshot are frozen on the transaction row |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-008: First payment determined by absence of a Posted transaction

| Field | Value |
| --- | --- |
| Statement | A claim is treated as not yet having a first payment until at least one of its financial transactions reaches Posted status. |
| Trigger | Reading `FirstPayment` on a transaction collection |
| Enforcement | `clsFinancialTransCollection.FirstPayment` |
| Outcome | Boolean consumed by callers to drive first-payment processing |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-009: Payment postings are insert-only

| Field | Value |
| --- | --- |
| Statement | A payment posting record can only be created; it can never be updated, deleted, or re-retrieved individually, and the request that supplied a status not in Released/Selected/Printed/BalanceReduced/Posted falls back to Released. |
| Trigger | Any attempt to update/delete/retrieve a single posting; retrieval by an unrecognized status |
| Enforcement | `clsPaymentPosting.Criteria` throwing `InvalidSQLProperty`; `clsPaymentPostingCollection.Criteria.FinancialTransactionStatusCode` `Case Else` |
| Outcome | `ApplicationException`, or silent fallback to status "1" |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-010: Claim payment totals are append-only and latest-sequence-wins

| Field | Value |
| --- | --- |
| Statement | Claim payment totals are never updated in place; each change writes a new row, only for cost categories whose paid amount or timeloss-day quantity changed, and the current total for a claim/category is the row with the highest sequence number (a category with no prior row starts from a zero baseline). |
| Trigger | Reading or saving current claim payment totals |
| Enforcement | `clsPaymentTotalManager.GetCurrentPaidCostsForClaim`, `BeforeInsert` (`If Cat.IsModified`) |
| Outcome | History preserved; totals derived from the newest row per category |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-011: Benefit period amount must reconcile to TD plus interest minus previously paid

| Field | Value |
| --- | --- |
| Statement | When the TD amount on a benefit period is greater than zero, the benefit amount must equal TD amount plus interest amount minus previously-paid amount; if that sum is negative, the benefit amount must be zero. TD days paid and previously-paid TD days must be in half-day increments, and supplemental (SupTD) periods carry no TD days. |
| Trigger | Benefit period validation |
| Enforcement | `clsBenefitPeriod.ValidBenefitAmt`, `ValidTdDays`, `ValidSupTdDays`, `ValidPreviousTdDays` |
| Outcome | Broken rule `clsClaimBenefitPeriod01` ("Error: Benefit amount is invalid.") or the matching day-increment error |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-012: Overlapping benefit periods of the same category are invalid

| Field | Value |
| --- | --- |
| Statement | Two benefit periods with the same payment category and non-empty dates may not have overlapping date ranges. |
| Trigger | Collection inspection before save |
| Enforcement | `clsBenefitPeriodCollection.HasOverlappingPeriods` |
| Outcome | Boolean flag consumed by callers to block/warn |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-013: Previously-paid history requires exact, gap-free coverage

| Field | Value |
| --- | --- |
| Statement | Prior payment history applies to a benefit period only when the minimum begin date and maximum end date of matching paid periods exactly equal the period's from/thru dates with no day gaps between them; supplemental history is additionally identified by reimbursement program 7, and penalty/interest-cost transactions are excluded from the match. |
| Trigger | `LoadPreviousPaidProperites()` on a benefit period |
| Enforcement | `clsBenefitPeriod.MatchingPreviouslyPaidPeriod`, `GetPreviouslyPaidPeriods` |
| Outcome | Previously-paid amount/days populated only on exact match; otherwise zeroed |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-014: Scheduled future payments are capped and roll to the next work day

| Field | Value |
| --- | --- |
| Statement | A benefit payment schedule may not carry more than the configured maximum future payments (14 when loaded through the collection), and every issue date after the first rolls back to the previous work day. |
| Trigger | Schedule validation and projection build |
| Enforcement | `clsBenefitSchedule.Rule_CheckMaxFuturePayments`, `clsBenefitSchedule.BuildPaymentProjections` |
| Outcome | Broken rule (empty message) when exceeded; issue dates adjusted to work days |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-015: A blank benefit remark code deletes the remark; a non-blank code must be active

| Field | Value |
| --- | --- |
| Statement | Saving a benefit remark with a blank pay-remark code deletes the remark row instead of updating it; a non-blank code must exist among unexpired codes in the remark code table. |
| Trigger | `clsBenefitRemark.Save()`; remark validation |
| Enforcement | `clsBenefitRemark.Save`, `Rule_CheckPayRemarkCode` + `GetPaymentRemarkCodes` |
| Outcome | Row deleted on blank; "Error: Invalid benefit remark." on an unrecognized non-blank code |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-016: Payee implementation is selected by payee type code

| Field | Value |
| --- | --- |
| Statement | A benefit payee row is dispatched to a concrete payee class by its stored type code (Attorney/MedicalProvider/Other/Unknown → provider payee; Beneficiary, Employer, Recovery, Support, Worker → their own class); any unmapped type falls back to the provider payee implementation. |
| Trigger | Payee load or creation |
| Enforcement | `clsPayeeFactory.GetClaimPayee` / `NewClaimPayee` |
| Outcome | Concrete payee subtype instantiated |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-017: Payment address required for a non-zero, non-award payee

| Field | Value |
| --- | --- |
| Statement | A non-award payee with a non-zero payment amount must have a payment address that is either foreign or passes the payee-type completeness check (worker/beneficiary validated address; employer/provider/support address line 1, city, state, and zip). Foreign, valid, non-empty addresses force special handling code `FGNML`. |
| Trigger | Payee validation; instantiation; provider-location change |
| Enforcement | `clsPayeeBase.Rule_CheckValidPaymentAddress`, `SetDefaultSpecialHandling` |
| Outcome | "Error: Payment address not found or is incomplete." or special handling set/cleared |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-018: Cash card identifiers must be numeric and within length limits

| Field | Value |
| --- | --- |
| Statement | A payee's cash card ID must contain no decimal point and be no more than 16 digits. |
| Trigger | Payee validation |
| Enforcement | `clsPayeeBase.Rule_CheckValidCashCardID` |
| Outcome | Broken rule; payment cannot save with an invalid cash card ID |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-019: Provider payees require a valid location and tax ID for non-zero payments

| Field | Value |
| --- | --- |
| Statement | When a provider payee's payment amount plus monthly payment amount is greater than zero and it is not an award payee, it must reference a valid provider location; a non-zero immediate payment also requires a non-blank tax ID. |
| Trigger | Provider payee validation |
| Enforcement | `clsProviderPayee.Rule_CheckValidProviderLocation`, `Rule_CheckValidProviderTaxID` |
| Outcome | Broken rule blocking save |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-020: Support payee requires an active support order for immediate payment

| Field | Value |
| --- | --- |
| Statement | A non-award support payee with a payment amount greater than zero requires the claim to have an active support order; an award-mode support payee may reference a terminated order. A stored support order that is no longer active is silently replaced by the claim's current active order when one exists. |
| Trigger | Support payee validation and `Fill` |
| Enforcement | `clsSupportPayee.Rule_ValidActiveSupportPayee`, `Rule_ValidSupportOrderID`, `GetSupportOrderID` |
| Outcome | "Error: This payee has no active support orders on file." / "Error: Support order is not on file."; order silently re-pointed on load |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-021: Auto-payee eligibility and de-duplication

| Field | Value |
| --- | --- |
| Statement | Automatic payees are generated as: Worker always; Support only with an active support order; Recovery when the claim has a non-deferred overpayment balance (for TD) or any overpayment balance (otherwise), seeded with the current overpayment balance; Attorney only with a legal-representative provider location; one Medical Provider per non-disputed, non-pharmacy-TPA, non-MCO-plan billing provider; one Beneficiary per claim beneficiary. Worker/Support/Recovery are unique by type; Attorney/Medical Provider are unique by provider location; Beneficiary is unique by person. |
| Trigger | Auto-payee generation on payment creation |
| Enforcement | `clsPayeeCollection.GetAutoPayees`, `GenerateAutoPayees` |
| Outcome | Candidate payee list built with duplicates skipped |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-022: Refund and transfer adjustments are mutually exclusive by concrete type

| Field | Value |
| --- | --- |
| Statement | A refund or transfer adjustment is implemented as one concrete class per mode (HWR, medical, non-disabling, other, SAIF-check, third-party, worker-travel refund; claim-to-claim, full, other transfer) rather than a single object with a runtime mode switch; the caller selects the concrete type at construction. |
| Trigger | Adjustment creation |
| Enforcement | `clsRefundAdjustment` / `clsTransferAdjustment` concrete subtypes |
| Outcome | Only the selected concrete type's logic and rule set run |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-023: Paid-cost and own-motion checks on refunds are overridable warnings

| Field | Value |
| --- | --- |
| Statement | Refund validation includes several warning-level checks (paid-costs review, own-motion reimbursement eligibility, pre-1966 claim dates, WBF reimbursements, third-party distribution/TD-day overages, preferred-worker non-disabling refunds) that the user may override; only error-level rules (such as remark length and TD-days decimal format) block the save. |
| Trigger | Refund validation |
| Enforcement | `Rule_CheckPaidCosts`, `Rule_CheckOwnMotion`, and related warning rules across the refund subtypes |
| Outcome | Warning surfaced but save proceeds if the user confirms; error-level rules block the save |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-024: Non-disabling and third-party refunds route through the external claim-data API

| Field | Value |
| --- | --- |
| Statement | Non-disabling reimbursement refunds and third-party refunds post their recovery/activity requests to the external ClaimCenter API and do not write directly to the legacy `CL_FINANCIAL_TRANS` tables, unlike every other refund and transfer type, which writes directly through `clsFinancialTrans`. |
| Trigger | Save of an `clsNdRefund` or `clsThirdPartyRefund` |
| Enforcement | `clsNdRefund` / `clsThirdPartyRefund` API request construction (`RecoveryRequest`, `ActivityRequest`) |
| Outcome | No legacy financial transaction row is created for these two refund types |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-025: Overpayment recoverable balance is enforced on settlement recovery payees, not on refund payments

| Field | Value |
| --- | --- |
| Statement | The only production enforcement of an overpayment-recovery-balance ceiling is on settlement payments: a Recovery payee's payment amount may not exceed the claim's current overpayment balance. `pk82395_overpayments.getRecoverableBalance` (the function named in BR-CP-003) appears only in test fixtures in this codebase and is not called by any production refund or settlement class traced. |
| Trigger | Settlement payment approval |
| Enforcement | `clsSettlementPayment.CheckApprovalErrors` (`Payees.Where(PayeeType = Recovery And PaymentAmount > ClaimData.OverpaymentBalance)`) |
| Outcome | "Error: Recovery payee amount is greater than the overpayment balance of {0}." |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-026: Bill payment adjustments require an eligible financial transaction

| Field | Value |
| --- | --- |
| Statement | A bill payment adjustment (transfer between claims or cost categories) reads its source financial transaction detail through `pk82343_financial_trans.SelectTranDetailForTransfer` and inserts a new `CL_FINANCIAL_TRANS_BILL_ADJUST` row recording the adjustment; the adjustment is a record of the transfer, not a reversal of the original transaction. |
| Trigger | Bill payment adjustment save |
| Enforcement | `clsBillPaymentAdjustment.BeforeInsert` |
| Outcome | New adjustment row persisted alongside the untouched original transaction |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-027: A released payment must remain in Released state to be deleted

| Field | Value |
| --- | --- |
| Statement | `clsPaymentDeleter` checks that the target payments are still in the Released financial-transaction status before deleting them; payments that have advanced to Selected, Printed, Balance-Reduced, or Posted cannot be deleted through this path. |
| Trigger | Payment deletion request |
| Enforcement | `clsPaymentDeleter.PaymentsStillInReleasedState` |
| Outcome | Deletion proceeds only for still-Released transactions |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-028: Award type must match the claim type

| Field | Value |
| --- | --- |
| Statement | A Fatal award may only be created for PTD or Fatal claim types; a PTD award requires the claim type to be PTD. |
| Trigger | Award validation |
| Enforcement | `clsFatalAward.Rule_MustBePTDFTLClaim`, `clsPTDAward.Rule_MustBePTDClaim` |
| Outcome | "Error: A Fatal award can only be created for PTD and Fatal claim types." (and the PTD equivalent) |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-029: Fatal and PTD award prerequisites

| Field | Value |
| --- | --- |
| Statement | A Fatal award requires a worker date of death and at least one claim beneficiary; a PTD award requires a valid worker birthdate and a non-zero average weekly wage, and a closure or order association. |
| Trigger | Award validation |
| Enforcement | `clsFatalAward.Rule_MustHaveWorkerDeathDate` / `Rule_MustHaveBeneficiaries`; `clsPTDAward.Rule_MustHaveWorkerBirthdate` / `Rule_MustHaveAverageWeeklyWage` |
| Outcome | Award cannot be validated/saved without the prerequisite data |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-030: Advance awards carry no effective date and no monthly payments

| Field | Value |
| --- | --- |
| Statement | An advance Fatal or PPD award must not have an effective date, and its total monthly payment amount must be zero; a non-advance award requires an effective date that is on or after the injury date (PTD additionally requires it on or before the closure-order date; PPD requires it not to be in the future). |
| Trigger | Award validation and approval |
| Enforcement | `Rule_EffectiveDateNotAllowedOnAdvance`, `Rule_EffectiveDateOnAdvance`, advance-monthly approval checks, `Rule_EffectiveDateGEDOI`, `Rule_EffectiveDateLEOrderDate`, `Rule_EffectiveDateNotInFuture` |
| Outcome | Save/approval blocked on violation |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-031: An award cannot be deleted once payments have been released

| Field | Value |
| --- | --- |
| Statement | An award marked for deletion cannot be deleted if a payment transaction has already been made against it, and its status cannot be set to Active while payment checks are in progress. |
| Trigger | Award delete / status change |
| Enforcement | `clsAward.Rule_CannotDeleteWithPayment`, `Rule_ValidAwardStatus` (`HasPaymentsInProgress` via financial-trans status codes 1-3) |
| Outcome | "Error: This award cannot be deleted because a payment transaction(s) has been made." / "Error: Active status is not valid while checks are in progress." |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-032: Award reduction ceilings by payee class and issue date

| Field | Value |
| --- | --- |
| Statement | Support-order reductions on an award payment are capped at 25% of the base amount for issue dates on or after the January 1, 2012 cutover (50% before); attorney/other-payee reductions are capped at 44%/63% depending on the same cutover. |
| Trigger | Award payment approval |
| Enforcement | Percentage approval rules in `clsFatalAward`/`clsPPDAward`/`clsPTDAward` (`PercentLimitChangeDate = #1/1/2012#`) |
| Outcome | Approval warning/error when a reduction exceeds the applicable ceiling |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-033: Award payment amounts are hard-capped and PPD lump-sum guidance applies

| Field | Value |
| --- | --- |
| Statement | A Fatal or PPD award payment (and every payee on it) is capped at $250,000; a first-time PPD award of $6,000 or less should be paid as a lump sum, while one over $6,000 should not be paid entirely as a lump sum. |
| Trigger | Payment instantiation; PPD approval |
| Enforcement | `clsFatalPayment.OnInstantiationComplete`, `clsPPDPayment.OnInstantiationComplete`, `Rule_ShouldBeLumpSum` / `Rule_ShouldNotBeLumpSum` |
| Outcome | Amounts above $250,000 cannot be entered; approval warning/error on the lump-sum mismatch |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-034: Granted Social Security offsets require complete date and amount data

| Field | Value |
| --- | --- |
| Statement | When a PTD award's Social Security offset status is Granted, it must carry a positive monthly amount, an effective date and order date on or after the injury date, and an expiration date on or after the effective date; offset date ranges for the same award may not overlap. A Denied status bypasses these checks. |
| Trigger | Social Security offset save/validation |
| Enforcement | `clsAwardSSOffset` rules (`Rule_AmountRequiredIfGranted`, `Rule_SSOEffectiveDate*`, `Rule_SSOOrderDate*`, `Rule_SSOExpirationDateRequired`, `Rule_ValidSSOExpirationDate`), `clsAwardSSOffsetCollection.Rule_DatesDoNotOverlap` |
| Outcome | Offset row rejected until the requirement is met |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-035: Award cash card format

| Field | Value |
| --- | --- |
| Statement | A cash card ID used on an award payee must be between 10 and 16 digits. |
| Trigger | Award payment approval |
| Enforcement | `clsAwardPayment.ApprovalRule_ValidCashCardID` |
| Outcome | "Error: Cash card must be between 10 and 16 digits." |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-036: Award payee types are restricted by award type

| Field | Value |
| --- | --- |
| Statement | A Fatal award payment allows only Attorney, Beneficiary, Other, and Recovery payees; a PPD/PTD award payment allows only Attorney, Worker, Other, Recovery, and Support payees. Any other requested payee type is silently converted to Other. |
| Trigger | Award payee creation |
| Enforcement | `clsAwardPayment.GenerateNewPayee` |
| Outcome | Payee created as the restricted type or downgraded to Other with no error raised |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-037: Award double-payment guard

| Field | Value |
| --- | --- |
| Statement | An award payment may not overlap a prior payment to the same payee/provider/reduction for the same payment category and date range on the same award. |
| Trigger | Award payment approval (Fatal, PTD) |
| Enforcement | `clsAwardPayment.GetPreviouslyPaidPayees` / `PreviouslyPaidPayeeList` |
| Outcome | `ApprovalErrors.PreviouslyPaidPayeeOverlap` |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-038: Duplicate timeloss payment guard

| Field | Value |
| --- | --- |
| Statement | An approved timeloss payment may not be saved if a matching TD financial transaction already exists for the same claim, benefit from/thru dates, issue date, total amount, and entry date. |
| Trigger | Save of an approved, non-deleted timeloss payment not loaded by payment ID |
| Enforcement | `clsTimelossPayment.TranExists` |
| Outcome | "Error: Duplicate payment can not be saved."; `Save` returns False |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-039: Minimum releasable timeloss benefit

| Field | Value |
| --- | --- |
| Statement | A non-zero timeloss payment must total at least $1.00 in aggregate, and individual payee amounts under $1.00 raise a warning; the sum of benefit-period amounts must equal the sum of payee payment amounts. |
| Trigger | Timeloss payment validation/approval |
| Enforcement | `clsTimelossPayment` payment-amount checks, `CheckApprovalWarnings` |
| Outcome | Error "Sum of TD benefit amounts must = sum of payment amounts." or a below-minimum error/warning |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-040: Timeloss reserves must cover scheduled payments

| Field | Value |
| --- | --- |
| Statement | A timeloss payment schedule's remaining payment count times the payment amount may not exceed the applicable timeloss/vocational reserve, unless the claim is own-motion reimbursable. |
| Trigger | Timeloss payment/schedule validation |
| Enforcement | `clsTimelossPayment` reserve check against `TDReserves` / `VocTDReserves` |
| Outcome | Error blocking the scheduled payment |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-041: Three-day waiting period and schedule eligibility for timeloss

| Field | Value |
| --- | --- |
| Statement | A timeloss benefit period may not overlap the statutory three-day wait unless the claim is payment-eligible (supplemental TD and a zero-amount TD accompanying period are exceptions); a payment schedule requires exactly one 14-day benefit period (or period pair) in a single category with no supplemental-TD period and no previously-paid amounts or days. |
| Trigger | Timeloss period/schedule validation |
| Enforcement | `Rule_CheckPeriodDatesOverlap3DayWait`, `CanSchedule`, `Rule_CheckValidSchedule`, `Rule_CheckNoPreviouslyPaidWithSchedule` |
| Outcome | Schedule creation refused or period save blocked |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-042: Supplemental TD eligibility

| Field | Value |
| --- | --- |
| Statement | Supplemental TD may only be paid when the injury/disability date is on or after January 1, 2002, secondary-employer average weekly wages are greater than zero, at least one secondary employer exists, and no TD days are recorded on the supplemental period once it is out of in-progress status. |
| Trigger | Timeloss payment category selection and validation |
| Enforcement | `clsTimelossPayment.PaymentCategoryList`, `Rule_CheckSupplementalWages`, `Rule_CheckSupplementalInjuryDate`, `Rule_CheckSupplementalTdDays` |
| Outcome | Supplemental TD category unavailable or save blocked |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-043: Timeloss reduction ceilings and monthly support cap

| Field | Value |
| --- | --- |
| Statement | Support deductions on a timeloss payment may not exceed 25% or 50% of the payment (whichever the closure-order type and issue-date cutover allow, taking the lower); combined non-worker deductions are capped at 44% or 63%; an individual attorney/other payee should not exceed 25%; and a support payee's total for the issue month may not exceed the support order's configured monthly maximum. |
| Trigger | Timeloss payment approval |
| Enforcement | `clsTimelossPayment.CheckApprovalWarnings`, `SupportMaxPct`, monthly support-total check |
| Outcome | Approval warning when a deduction exceeds its ceiling |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-044: Timeloss auto-payee maintenance and residual allocation

| Field | Value |
| --- | --- |
| Statement | A support payee is added to a timeloss payment when the claim gains a support order and removed when it loses one; a recovery payee is added when the overpayment non-deferred balance is positive and removed when it clears. Non-worker payees receive their percentage of the benefit rounded to the cent; the worker payee receives the remainder, so rounding differences and unallocated percentage always accrue to the worker. |
| Trigger | Timeloss retrieval validation; payee benefit allocation |
| Enforcement | `clsTimelossPayment.HandleChangeInSupportOrder` / `HandleChangeInRecoveryStatus`, `GetPayeeBenefitAmountLessInterest`, `RecalculatePayeeBenefitPercentages` |
| Outcome | Payee list mutated with a warning; worker amount absorbs rounding/residual |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-045: Timeloss issue date bounds and benefit period fiscal-year split

| Field | Value |
| --- | --- |
| Statement | A timeloss payment issue date may not be in the past or more than 28 days in the future, and must fall on a working day; a benefit period spanning July 1 is split into separate periods on either side of that date. |
| Trigger | Timeloss payment issue-date entry; period roll-forward |
| Enforcement | `Rule_CheckValidIssueDate`, `Rule_CheckIssueDateIsWorkingDay`, `UpdatePeriodsCrossingSplitDate` / `GetSplitDates` |
| Outcome | Broken rule on an invalid issue date; periods split at the fiscal-year boundary |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-046: Finalizing a timeloss wage worksheet freezes the statutory wage and discards in-progress worksheets

| Field | Value |
| --- | --- |
| Statement | Saving a primary or secondary wage worksheet with Final status and a positive wage amount sets the statutory weekly wage to that amount and stamps the finalizing user and date; saving a Final primary worksheet deletes every In Progress worksheet for the claim; verifying an auditor requires a Final worksheet to already exist. |
| Trigger | Wage worksheet save |
| Enforcement | `clsClaimTimelossCalculation.BeforeInsert/BeforeUpdate`, `RemoveInProgressRecords`, `AuditReviewerValid` |
| Outcome | Statutory wage frozen; in-progress worksheets removed; auditor verification blocked without a Final worksheet |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-047: Wage worksheet validation sets (primary and secondary)

| Field | Value |
| --- | --- |
| Statement | A primary wage worksheet must use calculation method Hourly or Dollar; a Final worksheet requires a paid amount greater than zero and a weekly pay-period unit; work-shift hours must be 1–99.99 for hourly units; wages must be 0–999,999.99; a secondary-employer worksheet must additionally name the employer and, when periods exist, use the same calculation-method restriction before it can be marked Final. |
| Trigger | Wage worksheet validation |
| Enforcement | `clsClaimTimelossCalculation.AddBusinessRules`, `clsSecTimelossCalculation.AddBusinessRules` |
| Outcome | Broken rule blocking the worksheet save |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-048: Active state award blocks or flags timeloss

| Field | Value |
| --- | --- |
| Statement | Retrieving a timeloss payment warns when the claim already has an active PPD, PTD, or Fatal award, when the claim is closed, when a recent payment exists on another claim for the same worker, when a BJO offset calculation is in progress, or when a support payee is on an abatement order. |
| Trigger | Timeloss payment retrieval |
| Enforcement | `clsTimelossPayment.CheckRetrievalWarnings` (`clsAward.GetAwardCount`) |
| Outcome | Warning surfaced to the adjuster; save is not blocked |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-049: Fixed 20-slot wage earnings grid

| Field | Value |
| --- | --- |
| Statement | Every wage calculation period (primary or secondary) exposes exactly 20 earnings-type rows; missing rows are padded in memory on load, and a dirty row with a blank earnings-type description is dropped before save. |
| Trigger | Loading or saving a wage calculation period's earnings collection |
| Enforcement | `clsWageCalcPeriodEarningsCollection.AfterRetrieve`, `RemoveUnusedEarningsRecords` |
| Outcome | Grid always shows 20 rows; padding rows never reach the database |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-050: Hourly and dollar wage entry are mutually exclusive per row

| Field | Value |
| --- | --- |
| Statement | A wage worksheet row is either hours times rate or a flat dollar amount, never both; setting one representation zeroes the fields belonging to the other. Gap-coded ("Excluded") periods do not contribute to the "less gap" wage totals. |
| Trigger | Data entry on a wage worksheet |
| Enforcement | `clsWageWorksheet.SetAmount`, `TotalsLessGapDisplay` |
| Outcome | Prior values in the other representation are overwritten; excluded periods omitted from totals |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-051: Only Final secondary wage worksheets feed multiple-employer wages and supplemental benefits

| Field | Value |
| --- | --- |
| Statement | Only secondary timeloss calculations flagged Final contribute to the claim's multiple-employer wage rollup and to supplemental (SupTD) benefit calculation; in-progress secondary worksheets are invisible to payment. |
| Trigger | `ProcessSecondaryWages()` on claim save; `GetSecondaryEmployers()` for supplemental wages |
| Enforcement | `clsInjuryClaimWageAndJob.ProcessSecondaryWages`, `clsSupplementalWages.GetSecondaryEmployers` (`wage_entry_status_type_code = 'F'`) |
| Outcome | Multiple-employer flag/amount and supplemental benefits derive only from Final worksheets |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-052: Legal order date blocked while secondary wage worksheets are in progress

| Field | Value |
| --- | --- |
| Statement | A claim's legal order date cannot be saved while any secondary wage worksheet is In Progress; the worker's hire date, when present, supersedes any manually entered tenure years/months/days. |
| Trigger | `clsInjuryClaimWageAndJob` validation and update |
| Enforcement | `LegalOrderDateSecInProgressValid` rule; `BeforeUpdate` tenure reset |
| Outcome | Save blocked with a directive error; tenure recomputed from hire date only |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-053: Offset wage earnings formula and rounding

| Field | Value |
| --- | --- |
| Statement | Offset wage earnings for a period equal (hours worked × hourly rate) plus (overtime hours × overtime rate), rounded to 2 decimal places using round-half-away-from-zero; a Daily wage type produces one offset period per calendar day, while BiWeekly produces one period per benefit period, and SupTD periods are excluded from the offset build. |
| Trigger | Offset wage calculation |
| Enforcement | `clsOffsetWageCalcPeriod.GetCalculatedEarnings` / `Earnings` setter, `clsOffsetWageCalculation.BuildCalcPeriods` |
| Outcome | Rounded per-period earnings stored and summed into `TotalOffsetWages` |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-054: Worker-adjusted average weekly wage formula

| Field | Value |
| --- | --- |
| Statement | A worker's adjusted average weekly wage for a benefit period equals (average weekly wage ÷ number of scheduled work days per week) multiplied by the days payable in the period; a half-shift period deducts 0.5 day, and a malformed (non-7-character) days-off string falls back to counting every calendar day as payable. |
| Trigger | Supplemental wage calculation; offset adjustment |
| Enforcement | `clsTimelossPayment.GetWorkerAdjustedAverageWeeklyWages`, `GetWorkerDaysPayable` |
| Outcome | Adjusted AWW feeds the supplemental shortfall and offset-amount adjustment |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-055: Supplemental wage shortfall reallocation

| Field | Value |
| --- | --- |
| Statement | Supplemental earnings for a SupTD period equal the adjusted average weekly wage minus actual secondary earnings for that period; a positive shortfall shifts excess primary-job earnings onto the supplemental period, while a negative value (over-earning on secondary jobs) reduces the offset on matching non-supplemental periods. |
| Trigger | `AssignOffsetWagesToPeriods` for SupTD benefit periods |
| Enforcement | `clsSupplementalWagePeriod.SupplementalEarnings`, `clsTimelossPayment.AssignOffsetWagesToPeriods` |
| Outcome | `OffsetAmount` / `OffsetAmountAdjusted` set on the affected benefit periods, directly changing the payable benefit |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-056: Offset rate entry required in Daily mode (warning only)

| Field | Value |
| --- | --- |
| Statement | An hourly rate is required whenever Daily-mode offset hours are entered, and an overtime rate is required whenever Daily-mode overtime hours are entered; these are warnings and do not block save. |
| Trigger | Offset wage calculation validation |
| Enforcement | `clsOffsetWageCalculation.CheckValidHourlyRate` / `CheckValidOvertimeRate` (`RuleType.Warning`) |
| Outcome | Warning surfaced; save proceeds |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-057: A responsible adjuster and non-void claim status are required to create a payment

| Field | Value |
| --- | --- |
| Statement | A payment cannot be created or retained unless the claim has an assigned, active responsible adjuster, and the claim status is not Void. |
| Trigger | Payment retrieval validation |
| Enforcement | `clsPaymentBase.Rule_CheckAssignedAdjuster`, `Rule_CheckClaimNotVoidOrInprogress` |
| Outcome | "A responsible adjuster must be assigned before creating payments." / claim-status error |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-058: Payment issue date bounds and working-day requirement

| Field | Value |
| --- | --- |
| Statement | A non-recurring or settlement payment's issue date must be a reasonable date, no more than the configured maximum future days (28 for the types traced) ahead of today, not earlier than the next scheduled issue date (unless it is a same-day rush check), and must fall on a working day. |
| Trigger | Payment validation |
| Enforcement | `clsPaymentBase.Rule_CheckValidIssueDate`, `Rule_CheckIssueDateIsWorkingDay` |
| Outcome | Broken rule blocking save |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-059: Medical bill payment cost-coding and MCO fee rules

| Field | Value |
| --- | --- |
| Statement | A medical bill payment's payee must be Worker or Medical Provider; an MCO fee is not valid on a non-chargeable bill or on a bill with IME services; the payment's claim cost category and reimbursement program are derived from the service category and, for own-motion-reimbursable claims, from the injury date relative to a claim-type-specific cutoff. |
| Trigger | Medical bill payment validation and cost-coding |
| Enforcement | `clsMedicalBillPayment.Rule_CheckPayeeTypeCode`, `Rule_CheckMCOPayment`, `Rule_CheckMCOPaymentWithIME`, `GetClaimCostInfo` |
| Outcome | Broken rule on an invalid payee/MCO combination; cost category/reimbursement program set per the derivation |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-060: Burial payment amount ceiling and payee restriction

| Field | Value |
| --- | --- |
| Statement | A burial payment's maximum amount is derived from the statutory bulletin-year amount as of the worker's fiscal-year death date (or the injury date, whichever governs); exceeding it raises a warning, and the payee must be the deceased worker's provider ("Other") or the worker record itself. |
| Trigger | Burial payment instantiation and validation |
| Enforcement | `clsBurialPayment.OnInstantiationComplete`, `Rule_CheckMaxBurialAmount`, `Rule_CheckValidPayeeType` |
| Outcome | Amount capped with a warning above the maximum; save blocked for a disallowed payee type |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-061: EAIP and penalty payment eligibility rules

| Field | Value |
| --- | --- |
| Statement | An EAIP payment requires a non-zero expense ID and a payment amount greater than $1.00; a penalty payment's payee must be Attorney, Worker, or Other, its payment category must be one of Medical/TD/PPD/PTD/Fatal, and its from date may not be after its thru date. |
| Trigger | EAIP / penalty payment validation |
| Enforcement | `clsEaipPayment.Rule_CheckExpenseId`, `Rule_CheckPaymentAmount`; `clsPenaltyPayment.Rule_CheckValidPayeeType`, `Rule_CheckValidPaymentCategory`, `Rule_CheckValidFromDate`/`Rule_CheckValidThruDate` |
| Outcome | Broken rule blocking save |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-062: An approved non-recurring payment is released, not retained, as a benefit-payment row

| Field | Value |
| --- | --- |
| Statement | Once a non-recurring payment (burial, EAIP, employer refund, penalty, medical bill) is approved and its financial transactions are successfully created, the payment's own `CL_BENEFIT_PAYMENT` row is deleted; the financial transaction is the permanent record, not the payment header. |
| Trigger | `Save()` on an approved non-recurring payment |
| Enforcement | `clsNonRecurringPaymentBase.Save` / shadowed `CreateFinancialTransactions`; `clsMedicalBillPayment.Save` |
| Outcome | No `CL_BENEFIT_PAYMENT` row remains after a successful release |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-063: EAIP payment approval bypasses the awaiting-approval authority gate

| Field | Value |
| --- | --- |
| Statement | Unlike every other non-recurring payment type, an EAIP payment's `Approve()` moves directly from initiation to Approved status without running the self-approval, cash-card, or rush-check awaiting-approval checks applied to other payment types. |
| Trigger | EAIP payment approval |
| Enforcement | `clsEaipPayment.Approve` override |
| Outcome | EAIP payments can be approved by their own initiator without the authority checks other payment types enforce |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-064: Settlement amount, distribution, and order-date consistency

| Field | Value |
| --- | --- |
| Statement | A settlement payment's total must be between $0.01 and $999,999.99, must equal the sum of its payee payment amounts, and its order-approved date must fall between the injury date and today (or be blank for a structured settlement). |
| Trigger | Settlement payment approval |
| Enforcement | `clsSettlementPayment.CheckApprovalErrors` |
| Outcome | "Error: Sum of benefit amounts must = settlement amount." / order-approved-date / amount errors |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-065: Settlement support deduction ceiling (warning)

| Field | Value |
| --- | --- |
| Statement | A settlement's support-order deduction is capped at 25% (issue date on or after the configured cutover) or 50% (before) of the total payment; this check is skipped for federal settlements. A support order with arrearage but no deduction also raises a warning. |
| Trigger | Settlement approval |
| Enforcement | `clsSettlementPayment.CheckApprovalWarnings` |
| Outcome | Approval warning, not blocking |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-066: DCS medical-provider statutory distribution cap

| Field | Value |
| --- | --- |
| Statement | Under a DCS statutory-minimum distribution, the total payable to medical providers is capped at 40% of the settlement total; each medical payee's audited amount is proportionally scaled down to fit within that cap, with the rounding remainder assigned to the last non-zero payee. |
| Trigger | `clsDCSPayment.DistributeAmounts(StatutoryMinimum)` |
| Enforcement | `clsDCSPayment.DistributeAmounts`, `GetMedProviderAmounts` |
| Outcome | Medical payee amounts scaled to the 40% cap |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-067: Legal-order payments can never be self-approved

| Field | Value |
| --- | --- |
| Statement | A legal-order payment can never be approved by its own initiator, regardless of that user's authority level. |
| Trigger | Legal-order payment awaiting-approval check |
| Enforcement | `clsLegalOrderPayment.AwaitingApprovalChecks` (`If InitiatorUser = CurrentUser.UserID Then Return ApprovalErrors.LegalOrder`) |
| Outcome | Approval refused unconditionally for self-initiated legal-order payments |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-068: No duplicate DCS or repeat CDA/federal settlement by the same initiator

| Field | Value |
| --- | --- |
| Statement | A DCS "Full" payment cannot be approved if a prior Full DCS payment already exists for the claim; a DCS "Partial" payment cannot repeat the same issue date and amount as a prior partial payment; a CDA or federal settlement payment cannot be approved by its initiator if that initiator has previously released a settlement of the same category on the claim. |
| Trigger | Settlement awaiting-approval checks |
| Enforcement | `clsDCSPayment` duplicate checks, `clsSettlementPayment.HasPreviouslyPaid` (CDA/federal) |
| Outcome | `ApprovalErrors.DCSMultipleFull` / `DCSDuplicatePartial` / `PreviouslyPaid` |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-069: CDA and DCS settlements trigger downstream claim-status side effects

| Field | Value |
| --- | --- |
| Statement | A released, non-structured CDA settlement on an open claim whose status-effective date is on or before the order-approved date closes the claim; a released, non-structured full DCS payment deactivates the claim and finalizes the denial status of any pending medical-condition compensability decision. |
| Trigger | Settlement `Save()` after successful release (CDA, DCS) |
| Enforcement | `clsCDAPayment.Save` override, `clsDCSPayment.Save` override, `UpdateClaimDecisions` |
| Outcome | Claim status set to Closed (CDA) or deactivated with denial finalized (DCS) |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-070: Federal settlement requires a federal jurisdiction and excludes medical providers from auto-payees

| Field | Value |
| --- | --- |
| Statement | A federal settlement payment requires the claim's jurisdiction to be federal, and its automatic-payee set excludes Medical Provider (unlike CDA and DCS settlements, which include it). |
| Trigger | Federal settlement retrieval validation; auto-payee generation |
| Enforcement | `clsFederalSettlement.Rule_IsFederal`; `clsFederalSettlement` auto-payee type list |
| Outcome | "Error: The claim's jurisdiction must be federal." on a non-federal claim; no automatic medical-provider payee |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-071: Confidential worker names are masked on payment lists

| Field | Value |
| --- | --- |
| Statement | When a payment's claim is flagged as a worker conflict, the worker's name is replaced with the literal value "Confidential" in payment-list output. |
| Trigger | Reading `WorkerName` on a payment-list row |
| Enforcement | `clsPaymentList.WorkerName` (`If Me.IsWorkerConflict Then "Confidential"`) |
| Outcome | Worker identity withheld from list consumers |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-072: Payment authority is limited by expiration date and configured maximum amount

| Field | Value |
| --- | --- |
| Statement | A user's initiate/approve authority for a payment business function excludes any limit past its expiration date, and permits initiating or approving only up to that limit's configured maximum amount. |
| Trigger | `HasAuthority` check during payment initiation/approval |
| Enforcement | `clsPaymentUser.PaymentAuthorities`, `HasAuthority` |
| Outcome | `ApprovalErrors.AuthorityLevel` / `NotAllowedToApprove` when the amount or expiration is out of bounds |
| Confidence | Source-backed |
| Source | See page sources |

---

## BR-CP-073: Non-disabling reimbursement is capped against the cumulative recovered amount

| Field | Value |
| --- | --- |
| Statement | A proposed non-disabling reimbursement is flagged when the claim's total recovered amount to date plus the proposed amount exceeds the claim's statutory maximum reimbursement amount, as reported by the claim-data API. |
| Trigger | Refund validation (`clsNdRefund.GetNDROverMax`) |
| Enforcement | External claim-data API `v1/GeneralClaimData/Claim/Nondisabling/ReimbursementAmounts`, compared against `TotalRecoveredAmount + NDRAmount` |
| Outcome | Claim added to the over-maximum list for adjuster review |
| Confidence | Source-backed |
| Source | See page sources |

---

## Notes

- Procedure-derived rules are mirrored here so claim-domain readers do not have to open procedure pages to see active constraints.
- Rules without BOF rule attributes are enforced by lifecycle methods, helper methods, or stored-procedure contracts.
- BR-CP-001 through BR-CP-003 were carried over unchanged from the prior documentation pass; BR-CP-004 through BR-CP-073 were added during the 2026-07-30 operations-and-processes rewrite, based on direct source tracing of every class under `Business\SAIF.Business.Claim.Payment\`. BR-CP-003's citation of `pk82395_overpayments.getRecoverableBalance` could not be confirmed against any production call site (only test fixtures reference it); BR-CP-025 documents the production overpayment-balance rule that was actually found, on `clsSettlementPayment`.

## Related documentation

- [Index](index.md)
- [Overview](overview.md)
- [Architecture](architecture.md)
- [Dependencies](dependencies.md)
- [Operations and processes](operations-processes.md)
- [Database tables](database-tables.md)
- [SQL catalog](sql/index.md)
- [Procedures](procedures/index.md)
- [API reference](api/index.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\clsBenefitRemark.vb`
- `Business\SAIF.Business.Claim.Payment\clsPaymentListCollection.vb`
- `Business\SAIF.Business.Claim.Payment\Adjustments\clsAdjustmentCategory.vb`
- `Business\SAIF.Business.Claim.Payment\FinancialTransaction\clsFinancialTrans.vb`
- `Business\SAIF.Business.Claim.Payment\FinancialTransaction\clsFinancialTransCollection.vb`
- `Business\SAIF.Business.Claim.Payment\FinancialTransaction\clsFinancialTransDtl.vb`
- `Business\SAIF.Business.Claim.Payment\FinancialTransaction\clsFinancialTranRemark.vb`
- `Business\SAIF.Business.Claim.Payment\FinancialTransaction\clsPaymentPosting.vb`
- `Business\SAIF.Business.Claim.Payment\Payees\clsPayeeBase.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\clsPaymentBase.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsBenefitSchedule.vb`
- `Business\SAIF.Business.Claim.Payment\Periods\clsBenefitPeriod.vb`
- `Business\SAIF.Business.Claim.Payment\Wage and Job\clsClaimTimelossCalculation.vb`
- `Business\SAIF.Business.Claim.Payment\Pipelines\build-vars.yml`
- `Business\SAIF.Business.Claim.Payment\packages.config`
- `Business\SAIF.Business.Claim.Payment\SAIF.BOF.Business.Claim.Payment.nuspec`
- `Business\SAIF.Business.Claim.Payment\Adjustments\Refunds\clsNdRefund.vb`
- `Business\SAIF.Business.Claim.Payment\Adjustments\clsBillPaymentAdjustment.vb`
- `Business\SAIF.Business.Claim.Payment\FinancialTransaction\clsFinancialTransDtlCollection.vb`
- `Business\SAIF.Business.Claim.Payment\FinancialTransaction\clsPaymentPostingCollection.vb`
- `Business\SAIF.Business.Claim.Payment\FinancialTransaction\clsPaymentTotalManager.vb`
- `Business\SAIF.Business.Claim.Payment\Payees\clsAwardPayeeInfo.vb`
- `Business\SAIF.Business.Claim.Payment\Payees\clsPayeeCollection.vb`
- `Business\SAIF.Business.Claim.Payment\Payees\clsSupportPayee.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsEmployerRefundPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\SettlementPayments\clsDCSPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\SettlementPayments\clsSettlementPayment.vb`
- `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\clsAwardSSOffset.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAwardSSOffsetCollection.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsBenefitScheduleCollection.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsOffsetWageCalcPeriod.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsOffsetWageCalcPeriods.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsOffsetWageCalculation.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsSupplementalWagePeriod.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsSupplementalWagePeriods.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsSupplementalWages.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsTimelossPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Periods\clsBenefitPeriodCollection.vb`
- `Business\SAIF.Business.Claim.Payment\Wage and Job\clsInjuryClaimWageAndJob.vb`
- `Business\SAIF.Business.Claim.Payment\Wage and Job\clsSecTimelossCalculation.vb`
- `Business\SAIF.Business.Claim.Payment\Wage and Job\clsSecWageCalcPeriodEarnings.vb`
- `Business\SAIF.Business.Claim.Payment\Wage and Job\clsSecWageCalculationPeriod.vb`
- `Business\SAIF.Business.Claim.Payment\Wage and Job\clsWageCalcPeriodEarnings.vb`
- `Business\SAIF.Business.Claim.Payment\Wage and Job\clsWageCalculationPeriod.vb`