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
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
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
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).
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.
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.
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.
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.
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.
"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.
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.
"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.
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.
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
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.
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).
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.
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.
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
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
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.
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.
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
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.
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.
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
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.
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.
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.
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
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
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.
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.
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.
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
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.
"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.
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.
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.
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.
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.
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.
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.
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)
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
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.
Note: Statements marked with * were inferred from code structure, naming
conventions, or contextual evidence where direct confirmation was not available
in source artifacts.