Documentation›Admin Guide›Chapter 3
Chapter 312 min readLast reviewed: May 2026

Payers & Contracts

Payers and contracts are the configuration backbone of every billing decision Rendum makes. This chapter covers the administrative side of managing them.

1. Adding a payer

From the Payers screen, click Add Payer. Provide:

  • Payer name — the legal name.
  • CMS contract ID — the federal identifier (H-number for MA plans).
  • Plan type — MA, MA-PD, SNP, or PACE.
  • Effective date — when this payer relationship started.

2. Active / inactive toggle

Deactivating:

  • Hides the payer from new billing runs by default.
  • Preserves all historical decisions, rosters, and audit packages.
  • Writes an audit row tagged PAYER_DEACTIVATED.

Reactivating is a one-click reverse. Use deactivation for ended contracts you want to preserve history for; use Delete (a separate, harder confirmation) only if you uploaded a payer in error.

3. Uploading a contract

From the payer detail or the Contracts screen, click Upload Contract. The PDF goes into the Layer 0 ingestion pipeline:

  1. PDF preflight + OCR if needed.
  2. Rule extraction (AI agent).
  3. Dual-pass validation.
  4. Confidence scoring per field.
  5. Citation correlation (each field linked back to the PDF region).

See End-User Guide Chapter 3 — Rules & Contracts for the reviewer-side workflow.

4. Reviewing and signing off

Open the contract. The review drawer surfaces every extracted field with its confidence tier badge. The Sign Off button activates when every MANDATORY_REVIEW / HUMAN_REQUIRED field is resolved. Signing off:

  • Marks the rule configuration as the active rule for the payer.
  • Auto-deactivates the prior active rule for the same payer.
  • Writes a RULE_SIGN_OFF audit row.
  • Triggers a recalculation of the current month's projected revenue.
  • Triggers the rule-drift detector to flag unexpected deltas vs the prior rule.

5. Amendments mid-quarter

Upload the amended contract; Layer 0 extracts. The amendment-simulator shows the dollar impact on the current month before sign-off. The simulator can produce a CSV of per-member deltas for finance review. Sign off when satisfied — the new rule becomes active, the prior auto-deactivates.

6. Mid-cycle overrides

For targeted changes without a full re-upload, OWNER and ADMIN can apply:

  • Per-member rate adjustment (one cycle).
  • Per-member billable-day override.
  • Retroactive correction on a completed run.

Each override writes an audit row and is reflected in the decision-replay trace. Overrides do not modify the persisted rule — they are layered at billing-run time.

7. Payer-file-schema lifecycle

Each payer has a persisted PayerFileSchema row that maps incoming eligibility file columns to the canonical fields the rules engine expects. When a schema drift is detected at ingestion time:

  • A SCHEMA_DRIFT_DETECTED exception is raised.
  • The offending ingestion job pauses.
  • You reconcile from the Payer detail page: accept the new schema, reject the file, or apply a one-time mapping override.

The bulk-migration path lets you replay historic files against a new schema definition.

Audit footprint

Every action writes an audit row:

  • PAYER_CREATED, PAYER_EDITED, PAYER_DEACTIVATED, PAYER_REACTIVATED, PAYER_DELETED
  • CONTRACT_UPLOADED, RULE_EXTRACTION_COMPLETED, RULE_FIELD_OVERRIDE, RULE_SIGN_OFF, RULE_AMENDED, RULE_OVERRIDE_APPLIED, RULE_REACTIVATED

Permissions summary

  • Add / edit / deactivate payers: OWNER, ADMIN
  • Delete payers: OWNER only
  • Upload contracts: OWNER, ADMIN, BILLING_MANAGER
  • Sign off contracts: OWNER, ADMIN (BILLING_MANAGER can review but not sign off)
  • Apply mid-cycle overrides: OWNER, ADMIN
  • View payer + contract history: every role
← Previous
Chapter 2 — Users & Roles