# SettlementStatusOverrideRecord

A model the API reference uses in a request or a response. The operation pages link every field typed as this model here.

A single audit record for an admin-driven manual override of a transaction's
`SettlementStatus`. Records are appended to
`overrideHistory` by the
`Transaction.OverrideSettlementStatus` domain method and rendered on the
transaction detail page so subsequent admins can see who changed the settlement
state, when, why, and from what value.

## Fields
- `previousStatus` ([SettlementStatus](https://devportal.demo.winkpg.io/docs/api/models/SettlementStatus.md)): The settlement status the transaction held before this override was applied. (nullable)
  Values:
  - `WaitingForSettlement`: Transaction is waiting to be settled with the processor
  - `SettlementSucceeded`: Settlement completed successfully with the processor
  - `SettlementFailed`: Settlement failed - requires review and retry (rollback)
  - `NotEligible`: Transaction is not eligible for settlement (voided, reversed, or not yet captured)
  - `SettlementInProgress`: Settlement is currently in progress with the processor.
  - `SettlementOnHold`: Settlement is on hold and cannot proceed at the moment.
  - `SettlementRolledBack`: Settlement was rolled back or reversed after a completed attempt. Distinct from SettlementFailed which indicates a transient failure needing retry.
  - `ReversalFailed`: A reversal was attempted but the processor did not confirm that the authorization hold was voided: the contributor saw a non-Ok result code (transport failure, timeout, swallowed exception, malformed response, etc.). Distinct from NotEligible (a confirmed reversal/void) and SettlementFailed (a settlement-time failure). Operations need to confirm the hold state with the processor and reverse manually if required. The transaction's Stage is left at the pre-reversal value; the close-stage history entry is NOT written.
  - `Pending`: The provider owns settlement and reports the outcome on its own schedule, so the transaction belongs to no gateway batch. Used for ACH sales and alternative payments. A background sync moves the transaction on as the provider reports, through any of the ACH in-flight statuses, to a terminal status.
  - `Accepted`: The ACH processor has accepted the transaction for processing. VeriCheck V2 only: the entry has been received and accepted by the payment network.
  - `Originated`: The ACH transaction has been originated (submitted to the NACHA network). VeriCheck V2 only: the debit has been forwarded to the RDFI.
  - `Verifying`: The ACH processor is verifying the bank account before origination. VeriCheck V2 only: the check runs on the processor's side, before the debit reaches the ACH network.
  - `PartiallySettled`: The ACH transaction has been partially settled. VeriCheck V2 only: a portion of the funds have cleared.
- `newStatus` ([SettlementStatus](https://devportal.demo.winkpg.io/docs/api/models/SettlementStatus.md)): The settlement status the operator selected. (nullable)
  Values:
  - `WaitingForSettlement`: Transaction is waiting to be settled with the processor
  - `SettlementSucceeded`: Settlement completed successfully with the processor
  - `SettlementFailed`: Settlement failed - requires review and retry (rollback)
  - `NotEligible`: Transaction is not eligible for settlement (voided, reversed, or not yet captured)
  - `SettlementInProgress`: Settlement is currently in progress with the processor.
  - `SettlementOnHold`: Settlement is on hold and cannot proceed at the moment.
  - `SettlementRolledBack`: Settlement was rolled back or reversed after a completed attempt. Distinct from SettlementFailed which indicates a transient failure needing retry.
  - `ReversalFailed`: A reversal was attempted but the processor did not confirm that the authorization hold was voided: the contributor saw a non-Ok result code (transport failure, timeout, swallowed exception, malformed response, etc.). Distinct from NotEligible (a confirmed reversal/void) and SettlementFailed (a settlement-time failure). Operations need to confirm the hold state with the processor and reverse manually if required. The transaction's Stage is left at the pre-reversal value; the close-stage history entry is NOT written.
  - `Pending`: The provider owns settlement and reports the outcome on its own schedule, so the transaction belongs to no gateway batch. Used for ACH sales and alternative payments. A background sync moves the transaction on as the provider reports, through any of the ACH in-flight statuses, to a terminal status.
  - `Accepted`: The ACH processor has accepted the transaction for processing. VeriCheck V2 only: the entry has been received and accepted by the payment network.
  - `Originated`: The ACH transaction has been originated (submitted to the NACHA network). VeriCheck V2 only: the debit has been forwarded to the RDFI.
  - `Verifying`: The ACH processor is verifying the bank account before origination. VeriCheck V2 only: the check runs on the processor's side, before the debit reaches the ACH network.
  - `PartiallySettled`: The ACH transaction has been partially settled. VeriCheck V2 only: a portion of the funds have cleared.
- `reason` (string): Free-text justification supplied by the operator. Required, trimmed, 5-500 chars. (nullable)
- `operatorUserId` (string(uuid)): The user id of the operator who applied the override. (nullable)
- `operatorUserName` (string): The display name of the operator at the time of the override (snapshot: does not  follow rename of the underlying user account). (nullable)
- `overriddenAt` (string(date-time)): UTC timestamp the override was applied. (nullable)

## See also

- [All documentation](https://devportal.demo.winkpg.io/llms.txt): the machine-readable index of every public page on this site.