---
title: Medical bill and non-recurring payment processing
summary: Validates, cost-codes, and approves one-time non-recurring payments (medical bill, burial, EAIP, employer refund, penalty), releasing each as a financial transaction rather than a retained benefit-payment row.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.Payment
reference_type: embedded
operation_id: OP-CP-12
trigger: An adjuster creates and approves a medical bill payment, burial payment, EAIP payment, employer refund, or penalty payment against a claim
---

# Medical bill and non-recurring payment processing

This operation covers `clsMedicalBillPayment` and the `clsNonRecurringPaymentBase` family (`clsBurialPayment`, `clsEaipPayment`, `clsEmployerRefundPayment`, `clsPenaltyPayment`), which share a common lifecycle: validate type-specific eligibility rules, get approved, and release as a permanent financial transaction rather than a retained benefit-payment record.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-CP-12 |
| **Trigger** | Adjuster creates one of `clsMedicalBillPayment`, `clsBurialPayment`, `clsEaipPayment`, `clsEmployerRefundPayment`, `clsPenaltyPayment` and calls `Approve()`/`Save()` |
| **Inputs** | Payee type, service/expense category, payment amount, from/thru dates, worker death date (burial), expense ID (EAIP) |
| **Outputs** | Released financial transaction (via [Payment posting and totals management](payment-posting-and-totals-management.md)); the payment's own `CL_BENEFIT_PAYMENT` row deleted after successful release |
| **Primary components** | `clsMedicalBillPayment`, `clsNonRecurringPaymentBase`, `clsBurialPayment`, `clsEaipPayment`, `clsEmployerRefundPayment`, `clsPenaltyPayment` |
| **Entry point** | `Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsNonRecurringPaymentBase.vb` |

## Steps

1. **Require a responsible adjuster and a non-void claim** ([BR-CP-057](../business-rules.md#br-cp-057-a-responsible-adjuster-and-non-void-claim-status-are-required-to-create-a-payment)). `clsPaymentBase.Rule_CheckAssignedAdjuster`/`Rule_CheckClaimNotVoidOrInprogress` block any payment (including these non-recurring types) when the claim has no active responsible adjuster or is Void.
2. **Validate the issue date** ([BR-CP-058](../business-rules.md#br-cp-058-payment-issue-date-bounds-and-working-day-requirement)). `Rule_CheckValidIssueDate`/`Rule_CheckIssueDateIsWorkingDay` require a reasonable date no more than 28 days in the future, not earlier than the next scheduled issue date (unless a same-day rush check), and on a working day.
3. **Validate medical bill payee and MCO fee coding** ([BR-CP-059](../business-rules.md#br-cp-059-medical-bill-payment-cost-coding-and-mco-fee-rules)). `clsMedicalBillPayment.Rule_CheckPayeeTypeCode` requires the payee to be Worker or Medical Provider; `Rule_CheckMCOPayment`/`Rule_CheckMCOPaymentWithIME` block an MCO fee on a non-chargeable bill or one with IME services.
4. **Derive claim cost category and reimbursement program** ([BR-CP-059](../business-rules.md#br-cp-059-medical-bill-payment-cost-coding-and-mco-fee-rules)). `GetClaimCostInfo` derives these from the service category and, for own-motion-reimbursable claims, from the injury date relative to a claim-type-specific cutoff.
5. **Cap and restrict a burial payment** ([BR-CP-060](../business-rules.md#br-cp-060-burial-payment-amount-ceiling-and-payee-restriction)). `clsBurialPayment.OnInstantiationComplete`/`Rule_CheckMaxBurialAmount` derive the maximum from the statutory bulletin-year amount as of the worker's fiscal-year death date (or injury date); exceeding it warns rather than blocks. `Rule_CheckValidPayeeType` requires the payee to be the deceased worker's provider ("Other") or the worker record itself.
6. **Validate EAIP eligibility** ([BR-CP-061](../business-rules.md#br-cp-061-eaip-and-penalty-payment-eligibility-rules)). `clsEaipPayment.Rule_CheckExpenseId`/`Rule_CheckPaymentAmount` require a non-zero expense ID and an amount greater than $1.00.
7. **Validate penalty payment eligibility** ([BR-CP-061](../business-rules.md#br-cp-061-eaip-and-penalty-payment-eligibility-rules)). `clsPenaltyPayment.Rule_CheckValidPayeeType` restricts the payee to Attorney, Worker, or Other; `Rule_CheckValidPaymentCategory` restricts the category to Medical/TD/PPD/PTD/Fatal; `Rule_CheckValidFromDate`/`Rule_CheckValidThruDate` require the from date not to be after the thru date.
8. **Load employer refund cost caps** ([SQL-053](../sql/SQL-053.md), [CLAIM_NON_DISAB_REIMB_MAX](../database-tables.md#claim_non_disab_reimb_max)) — `clsEmployerRefundPayment` consults this table for reimbursement-maximum context (see also [BR-CP-073](../business-rules.md#br-cp-073-non-disabling-reimbursement-is-capped-against-the-cumulative-recovered-amount) in [Refund adjustment processing](refund-adjustment-processing.md), which governs the same cumulative-cap concept for refunds).
9. **Approve the payment.** Every non-recurring type except EAIP runs the standard awaiting-approval authority checks (self-approval, cash-card, rush-check) inherited from `clsPaymentBase`/`clsNonRecurringPaymentBase`.
10. **Bypass the authority gate for EAIP** ([BR-CP-063](../business-rules.md#br-cp-063-eaip-payment-approval-bypasses-the-awaiting-approval-authority-gate)). `clsEaipPayment.Approve` moves directly from initiation to Approved without running the self-approval, cash-card, or rush-check checks applied to every other payment type.
11. **Create financial transactions on release.** `CreateFinancialTransactions` (base, shadowed per type) posts the payment through [Financial transaction and remark management](financial-transaction-and-remark-management.md) and [Payment posting and totals management](payment-posting-and-totals-management.md).
12. **Delete the benefit-payment header after successful release** ([BR-CP-062](../business-rules.md#br-cp-062-an-approved-non-recurring-payment-is-released-not-retained-as-a-benefit-payment-row)). Once financial transactions are successfully created, `clsNonRecurringPaymentBase.Save`/`clsMedicalBillPayment.Save` delete the payment's own `CL_BENEFIT_PAYMENT` row — the financial transaction becomes the sole permanent record of the payment.

## Process flow

```mermaid
flowchart TD
	Start([Adjuster creates non-recurring payment]) --> AdjusterCheck{Responsible adjuster<br>assigned; claim not Void?}
	AdjusterCheck -->|No| Blocked1([Blocked])
	AdjusterCheck -->|Yes| IssueDate{Issue date valid<br>and working day?}
	IssueDate -->|No| Blocked2([Blocked: invalid issue date])
	IssueDate -->|Yes| TypeRules{Type-specific rules<br>satisfied?}
	TypeRules -->|No| Blocked3([Blocked: type-specific violation])
	TypeRules -->|Yes| PaymentType{Payment type?}
	PaymentType -->|EAIP| BypassGate[Approve directly;<br>bypass authority checks]
	PaymentType -->|Other| StdApproval{Standard awaiting-approval<br>checks pass?}
	StdApproval -->|No| Blocked4([Blocked: approval error])
	StdApproval -->|Yes| CreateTrans
	BypassGate --> CreateTrans[Create financial transactions]
	CreateTrans --> Success{Transactions<br>created successfully?}
	Success -->|No| Blocked5([Save fails; header retained])
	Success -->|Yes| DeleteHeader[Delete CL_BENEFIT_PAYMENT<br>header row]
	DeleteHeader --> Done([Payment released;<br>financial transaction is record])
```

## Failure and edge-case behavior

- Because EAIP payment approval bypasses the authority gate entirely ([BR-CP-063](../business-rules.md#br-cp-063-eaip-payment-approval-bypasses-the-awaiting-approval-authority-gate)), an EAIP payment's initiator can approve their own payment — a deliberate exception, not an oversight, but one worth flagging to anyone auditing separation-of-duties controls.
- Since the benefit-payment header row is deleted after release ([BR-CP-062](../business-rules.md#br-cp-062-an-approved-non-recurring-payment-is-released-not-retained-as-a-benefit-payment-row)), any UI or report that queries `CL_BENEFIT_PAYMENT` directly for a released non-recurring payment will not find it — only the resulting financial transaction remains.
- Burial payment amounts above the statutory maximum are permitted with only a warning, not blocked, so this cap is advisory rather than hard-enforced at this layer.
- MCO fee validation on medical bill payments is a binary allow/block based on chargeability and IME-service flags; there is no partial-fee or prorated-fee handling visible in this layer.

## 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\MedicalBillPayments\clsMedicalBillPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsNonRecurringPaymentBase.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsBurialPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsEaipPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsEmployerRefundPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsPenaltyPayment.vb`
- `Business\SAIF.Business.Claim.Payment\Payments\clsPaymentBase.vb`